Allow to specify the output file for --timings

[glandium]

Problem

Using cargo build --timings creates a target/cargo-timings/cargo-timing-YYYYMMDDTHHMMSSZ.html file as well as a symbolic link target/cargo-timings/cargo-timing.html. The only way to reliably know the exact file that a specific invocation of cargo has created is to parse its output and look for "Timing report saved to" (relying on the symbolic link is not time-resistant).

Proposed Solution

It would be useful to allow e.g. cargo build --timings=/path/to/my-report.html that would make cargo create said file instead of target/cargo-timings/cargo-timing-YYYYMMDDTHHMMSSZ.html. Whether it should skip creating a symbolic link or not is an open question.

--timings=html and timings=json would still have their current meaning, and the extension of the file would determine the format (i.e. --timings=/path/to/report.json would create a file with the json format)

Notes

No response

[epage]

Could you expand on why you need to know the file and why this solution works better compare to the symlink?

[glandium]

Stupid example: Run cargo build --timings and cargo build --timings --release at the same time in two terminals. Without looking at the output in each terminal, how do you tell which html file is from which build?

Now, that's not a super-realistic example, but consider something like a build system that invokes cargo to build two different crates in a workspace, the second of which already has been built, so that by the time the build system has figured the first has finished and looks at the symlink, the second, which was a no-op already changed the symlink.

[weihanglo]

I had a vague impression that the Cargo team had a discussion about storing timing data in a SQLite-ish local database, and might want to extend those data as profiles for future PGO in Cargo. If that is going to be implemented, this proposal might be less useful.

So put it in a broader scope — Cargo should have a reliable way to persist and retrieve timing data, might be related to https://github.com/rust-lang/cargo/issues/10410.

[epage]

Such an effort could have some synergy with #1989 and #2904

We could have cargo report rebuild, cargo report timings, etc.

[Aranjedeath]

I am also interested in a solution to this problem, perhaps not the same as OP but a solution nonetheless. I am regularly running cargo build --release --timings, and at one point realized these are stored in the project folder by default. Which means all the timings outputs are wiped out if you try to throw git in the sea and start over.

I was originally hoping for a ... default output location such as ~/.cargo/timings/* (or whatever would be similar and appropriate). I can also see a second issue after reading the back and forth here, which is that the current file name is timestamp-based and so does not really communicate anything about the build itself. It could.