https://pantsbuild.org/ logo
Join Slack
Powered by
For anyone who has experimented with this - does a...
# development
w
For anyone who has experimented with this - does anyone know how reliable an indicator our 
cargo bench
would be for perf changes? I'm looking into link time optimization, which is rough on compile times, but could be good for runtime. I would need a reliable indicator before there is any indication whether the value is there compared to the compile cost
Not just LTO, but other measures - just wondering how much work I need to do on our underlying stuff first
p
Can things like that be turned on just for the final release build so that it doesn't slow down test cycles (esp switching between branches or pulling or fast-forwarding triggering an engine re-compile)?
(I'm wouldn't even classify myself as a beginner in rust. I can kinda-sorta read it and I've poked it with a stick a few times.)
And it could also be triggered for 
automation:release-prep
labeled builds so that we have an indicator of issues in tests before doing that final release build.
w
Yeah, that would be the long-term idea - run it in a subset. But it still take a looong time to compile, even on my machine - so unless there is a lot of tangible return, I wouldn't even want to run it in CI
That's even just using the 
thin
LTO
I like your idea of using 
release-prep
as a potential label. I wanted to make a change, where using our local (dev) workflow would compile with codegen units set back to default, as it's substantially quicker for local iteration (similar to just using Dev mode, if we find that we can remove the original optimization soon)
Open in Slack
PreviousNext
Powered by