Tracking issue for -Ztimings

[ehuss]

Implementation: #7311
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#timings

It's not clear at this time if this will ever be stabilized, as it is just an experiment for now.

[andjo403]

this is super nice feature

• can be good to either be able to select the out dir or put the out files in the target-dir as some ci flows do not alow changes in the repo.
• maybe have the crate name in the file name. eg. when I did a test build in rustc there was alot of files but I was only interested in one create.

[luser]

From #4164, it would be nice if we could get this output in a machine-readable file. The JSON output is currently generated on stdout.

[bitshifter]

I was trying to use the json output to summarize build timings. The json output doesn't include the start time which limits what you can do with it. It might also be good to output a full summary similar to what is at the top of the html file, with total build time etc in it. For now I'm just parsing the info output instead.

[gilescope]

I think the cargo-timings.html and friends are super - the only slight tweak I'd ask is could we generate them to CARGO_TARGET_DIR dir as it can be a little scruffy if there's a lot of these generated files about? Also then cargo clean would remove them.

[cceckman]

This is an awesome feature. Added it to a personal project; looked at the HTML output; immediately saw a large and unnecessary dependency chain that let me speed up builds by ~20%.

[matklad]

Random thought: seeing the times to build the crate by default seems rather important. It's much easier to get the feel for the project's overall compile times if you see the per-crate stats all the time.

Is there any chance we can include timings by default? Ie, changing

Compiling hir v0.0.0 (/home/matklad/projects/rust-analyzer/crates/hir)

to

Compiled hir v0.0.0 (/home/matklad/projects/rust-analyzer/crates/hir) in 3.2s

and printing the messages at the end of crate's compilation, rather than at the start?

If we design Cargo from the start, I'd feel strongly about going with the second option. Today, given that a whole bunch of tools are parsing "Compiling" messages (even if you are not supposed to), I am not sure if the switch makes sense.

[gilescope]

+1 - at the moment we have to do cargo -v to get the times but given that anything non-trivial is going to care about timings it's really helpful. I would be all for having those per-crate timings output as default.

…

On Thu, Dec 3, 2020 at 11:41 AM Aleksey Kladov ***@***.***> wrote: Random thought: seeing the times to build the crate *by default* seems rather important. It's much easier to get the feel for the project's overall compile times if you see the per-crate stats all the time. Is there any chance we can include timings by default? Ie, changing Compiling hir v0.0.0 (/home/matklad/projects/rust-analyzer/crates/hir) to Compiled hir v0.0.0 (/home/matklad/projects/rust-analyzer/crates/hir) in 3.2s and printing the messages at the end of crate's compilation, rather than at the start? If we design Cargo from the start, I'd feel strongly about going with the second option. Today, given that a whole bunch of tools are parsing "Compiling" messages (even if you are not supposed to), I am not sure if the switch makes sense. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7405 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGEJCF24URGU75QC5SM2ALSS52ODANCNFSM4IY733ZA> .

[ehuss]

In #8889 (comment), Alex suggested reworking the output completely so that it no longer spews out "Compiling" messages, and just have a short report when it finishes.

[gilescope]

Actually I do have one very small nit on the -Ztimeings front while we're on the subject - the html report is excellent but for neatness it would be great if it was generated in the target/debug directory so that it was cleaned up with cargo clean.

…

On Thu, Dec 3, 2020 at 4:29 PM Eric Huss ***@***.***> wrote: In #8889 (comment) <#8889 (comment)>, Alex suggested reworking the output completely so that it no longer spews out "Compiling" messages, and just have a short report when it finishes. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7405 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGEJCHAEWKJRQB2J6H46X3SS64FVANCNFSM4IY733ZA> .

[matklad]

It's not clear at this time if this will ever be stabilized, as it is just an experiment for now

@ehuss I've been using -Ztimnigs regularly for the past several years, and it has been instrumental in keeping compile-times of rust-analyzer in check. More broadly, as people start building complex applications in Rust, bad compile times are a common trope. So build-timings might give a tiniest ecosystem-wide nudge to care more about build times.

As such, I'd personally would love to see this on path to stabilization!

[joshtriplett]

Stabilization PR to stabilize -Ztimings as --timings: #10245

Note that this only stabilizes the info and html formats, and keeps --timings=json as unstable (requiring -Zunstable-options) until we're prepared to commit to a stable format.

[ehuss]

I'm going to close this as this was mostly stabilized in 1.60. I've moved tracking of the JSON option to #10857.