Problem
Over at Zed, we've noticed (and communicated to the members of the Cargo team) that there's a non-negligent cost to running builds with Cargo even prior to any rustc work starting. We've first started digging into it after noticing that there's a gap between a start of the first dirty crate in a graph and the epoch, as indicated in the following (non-representative) screenshot:
Another way to measure the overhead of cargo is to measure the time for a fully cached build (cargo b; time cargo b). In case of Zed, it's 0.6s or so.
Now, there's CARGO_LOG_PROFILE we used to get better understanding what's taking up that much time and it led to some observations (e.g. https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/Parallelizing.20parts.20of.20cargo) . Overall we are at least aware that some of our build time can be attributed to Cargo itself.
However, I think it is a bit problematic that the time spent in Cargo is surfaced only implicitly, via means described above. It's a blind spot in the breakdown of total time spent building.
Proposed Solution
I think it would be nice to surface that information somehow in the output of Cargo timings - be it a figure in the summary table at the top or (IMHO better) as some kind of special node within the graph itself.
I can see how there could be concerns with surfacing such info:
- For most users time spent in cargo should be miniscule. However, timings files already introduce moot nodes for Fresh units, so I don't think an extra one would do much harm - even in case where time spent in cargo is insignificant.
- How precise should the surfaced info be? I don't think we need to go to extra lengths with surfacing e.g. registry refetching versus parsing TOMLs and what have you - that's what
CARGO_LOG_PROFILE is for. I believe that having some information surfaced more explicitly should at least prompt users into looking into performance of Cargo on their projects more - and that is a good outcome (in my book).
Notes
No response
Problem
Over at Zed, we've noticed (and communicated to the members of the Cargo team) that there's a non-negligent cost to running builds with Cargo even prior to any rustc work starting. We've first started digging into it after noticing that there's a gap between a start of the first dirty crate in a graph and the epoch, as indicated in the following (non-representative) screenshot:
Another way to measure the overhead of cargo is to measure the time for a fully cached build (
cargo b; time cargo b). In case of Zed, it's 0.6s or so.Now, there's
CARGO_LOG_PROFILEwe used to get better understanding what's taking up that much time and it led to some observations (e.g. https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/Parallelizing.20parts.20of.20cargo) . Overall we are at least aware that some of our build time can be attributed to Cargo itself.However, I think it is a bit problematic that the time spent in Cargo is surfaced only implicitly, via means described above. It's a blind spot in the breakdown of total time spent building.
Proposed Solution
I think it would be nice to surface that information somehow in the output of Cargo timings - be it a figure in the summary table at the top or (IMHO better) as some kind of special node within the graph itself.
I can see how there could be concerns with surfacing such info:
CARGO_LOG_PROFILEis for. I believe that having some information surfaced more explicitly should at least prompt users into looking into performance of Cargo on their projects more - and that is a good outcome (in my book).Notes
No response