https://pantsbuild.org/ logo
Join Slack
Powered by
<@U051221NF> <@U0N6C2Q9F> Thoughts on whether this...
# development
w
@happy-kitchen-89482 @fast-nail-55400 Thoughts on whether this is still needed in the top-level Cargo.toml? I would have thought after call-by-name, rule_graph solving would be less-egregious. And even if we need to keep it, shouldn't this setting only affect that crate?
Copy code
[profile.dev]
# Increase the optimization level of the dev profile slightly, as otherwise `rule_graph`
# solving takes prohibitively long.
opt-level = 1
FWIW this literally doubles debug build time (50s to 100s), and triples incremental (3s to 10s) builds on my machine. If the concern is around 
test
profiles, we could also just set something there. Everything is slower already in debug, so 🤷
Ditto re: release mode - if we split up profiles for "CI Release" and "local release" - we could put even more optimizations on the CI release, and loosen the local release mode, to speed that compilation up substantially (e.g. default codegen units, not 1)
f
My thought is we collectively have not revisited the 
opt-level
choice in a while, so it is worth testing whether it is still needed or not.
h
I would like to err on the side of faster iterative debug builds...
w
Then I guess the question is more about whether we need opt-level 1 at all, or if we should retain it in the rule_graph crate. I don't think it should apply to all dev. From strictly a startup POV, the performance didn't change - took 1.5seconds to get 
pants --version
with all debugs, but that doesn't speak to whether more complicated queries would be better/worse (I can't assume it would be that different though)
I can remove debug opt-level in my next PR and we can see if any of our cargo test stuff gets noticeably slower 🤷 If not, leave if off is what I say.
So, after some updates - this is where the bulk of our build time is coming from on 
cargo build --release
- swapping release codegen units to default from 1 reduces engine build time by a factor of 3-4 That brings back the concept of splitting up "local release" and "CI release" profiles. CI release, we'd probably add some extra optimization, while local, I think we're fine with the default codegen for the time savings. Also added debug build times - a lot of the same offenders. Docker + Bollard are a pain, but aws-lc-sys build script dwarfs everything
c
That's a cool graph!
f
aws-lc-sys
is the default backend these days for RustTLS, but it can be switched back to the 
ring
crate.
Can we select different create features for 
rustls
between "local release" and "CI release" profiles?
The downside is not using the same TLS implementation between local development and CI, but given Pants is not a TLS product, we aren't testing TLS behavior any way.
w
Oh, I never thought of that. I’ve not tested it, but swapping features (or maybe even TLS implementations) in different dev/release/local could be interesting. I’ll investigate that idea further.
Screenshot 2026-02-25 at 17.14.10.png
Swapping aws to ring locally shaved about 25 seconds off my release build (default codegen units)
10 seconds off debug builds, and cargo check incremental is sub-second. I'm positive I can keep pulling this down, now that it's easier to see what is taking up the remaining time. Bollard/Docker will probably happen when I reach that part of my breaking change dep upgrades.
Open in Slack
PreviousNext
Powered by