cargo scripts cannot be run in release mode without workarounds

[ds84182]

In the motivation section of the cargo script RFC there are 3 main motivations: collaboration, prototyping, and one-off utilities.

Collaboration? Sometimes reproduction cases require release mode to reproduce an issue.

Prototyping? If prototyping something other than a bog standard "hello world" (like working with images) you'll definitely run into performance issues.

One-off utilities? The dev profile is so slow that a single file bash or python script could accomplish some tasks significantly faster. Again, image processing, for example.

The only use case where compilation time would really matter to someone is when prototyping.

As a workaround it is possible to change the dev profile in the embedded manifest to match the default release profile, but being able to specify --release in the shebang line would be so much simpler.

I also think it would be beneficial to default to opt-level = 1 for dev builds, since it doesn't add much compilation overhead but improves runtime performance significantly.

Test script:

#!/usr/bin/env -S cargo -Zscript
---
[profile.release] # replace with dev to enable release
opt-level = 3
overflow-checks = false
debug = 0
debug-assertions = false
lto = true
incremental = false
codegen-units = 16

# uncomment for opt-level = 1 instead of 0
# [profile.dev]
# opt-level = 1

[dependencies]
image = { version = "0.25", default-features = false, features = ["png"] }
rand = "0.10"
---
fn main() {
    // A one-off utility to generate an opaque PNG with random pixels.
    const WH: usize = 4096;
    use rand::{Rng, SeedableRng};
    let start = std::time::Instant::now();
    let mut rng = rand::rngs::Xoshiro128PlusPlus::from_rng(&mut rand::rng());
    let pixels = (0..(WH * WH)).flat_map(|_| (rng.next_u32() | 0xFF000000).to_le_bytes()).collect::<Vec<u8>>();
    image::save_buffer("imagefoo.png", &pixels, WH as u32, WH as u32, image::ColorType::Rgba8).unwrap();
    println!("{:?}", start.elapsed());
}

With the default dev profile this takes 10 seconds. With opt-level 1 this takes 790ms, and with release mode this takes 170ms.

You could do the same in bash with imagemagick, which would be much faster than the default dev profile's performance.

[epage]

Going back to the RFC

From https://rust-lang.github.io/rfcs/3502-cargo-script.html#cargo-filers

--release is not passed in because the primary use case is for exploratory programming, so the emphasis will be on build-time performance and debugging, rather than runtime performance

Improving this situation was left as a futore possibility at https://rust-lang.github.io/rfcs/3502-cargo-script.html#access-to---release-in-shebang as we are focusing on an MVP. This is one of many features pushed off, like being a workspace member.

This issue would then serve as a good place for coordinating that future work. I at least do not have the energy to drive such discussions.

As for the subject of profile defaults, something I worked on along the way to stabilization was reducing special cases. We are working on splitting the dev and debug profiles. I was hoping that would mean opt-level = "1" could be the default for dev but that is looking less likely. This is being tracked in #15931.

[ds84182]

While I understand the desire to keep special cases to a minimum, I think slow performance fundamentally makes cargo script way less useful by default and at first glance it isn't clear how to fix it. So in anticipation of #15931 it would be good to proactively change it for cargo script (since it's unstable) to dogfood the change, and then reevaluate from there.

However I am on the fence as to whether this is important enough to get into the MVP. There's sorta a "chicken and the egg" problem. It should be useful for people writing scripts that glue together well-known crates for processing lots of data (again, image processing comes to mind), but how many people will be doing things like this in a script? Can't really tell until it's more widely used.

When stable I think crate authors would start adding cargo scripts to their "getting started" documentation, for things like short demonstrations. Like a quick rapier2d example using winit and a 2d drawing library. Or an egui example. etc. These are things that would give negative impressions if built with opt-level 0.

[weihanglo]

FWIW, we are discussing different default profiles for different scenarios #17215. There might be a room for script.profile.

[epage]

Also, for deps that "can't" run in dev profile, we are introducing hints.min-opt-level for them to raise their opt-level even in dev. We are tracking this in #17334.

[epage]

When stable I think crate authors would start adding cargo scripts to their "getting started" documentation, for things like short demonstrations. Like a quick rapier2d example using winit and a 2d drawing library. Or an egui example. etc. These are things that would give negative impressions if built with opt-level 0.

Something to keep in mind is that there are a wide variety of use cases for cargo script. For some, this is important. For others, they won't be touching these runtime heavy crates and compile times will be most important.