r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

@bors try @rust-timer queue

☀️ Try build successful (CI)
Build commit: 0917255 (0917255b7c3d3d8f1c57be901c49970fb3ad0028, parent: a1208bf765ba783ee4ebdc4c29ab0a0c215806ef)

Finished benchmarking commit (0917255): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

Max RSS (memory usage)

Cycles

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 466.26s -> 486.484s (4.34%)
Artifact size: 388.41 MiB -> 410.15 MiB (5.60%)

Ok, still bad: I'll try to find some time to root cause the regression

Huh, so on Windows I see a 1% binary size improvement for rustc_driver, seems like it's from tokio-rs/tracing#2555.

Digging into the Linux side of things now (may take longer since I'm less familiar with it...)

For the Linux binary size regression, it seems to be caused by a bunch of new __CALLSITE and __CALLSITE::META static fields, which get added with every use of a tracing macro (went from ~2000 to ~8000 in the driver). I'm not sure if there's an way to remove them, or prevent them from being added to the symbol table?

I'm still looking into the instruction count regression. Not sure if those statics are part of it (additional startup costs to init them or apply relocs?).

Finally figured out how to repro this locally: I needed to use the dist profile in bootstrap, as the compiler profile enables debug logging.

I confirmed this by looking at the rustc_mir_transform::coroutine::compute_layout function: before the update it had no CALLSITE or META statics associated with it, but afterwards there are 6 of each. It also increased in binary size by about 70%. If you look at the sources, there are 6 debug! statements and no other traces, so they should have been optimized away when debug logging was disabled, but haven't been (for some reason).

I think I found the issue. We need to put max_level_info = ['tracing/max_level_info', 'tracing/release_max_level_info'] into rustc_log/Cargo.toml. Could you try it please? I'll do another perf. run.

Actually, figured I could try it myself =D Hope you don't mind.

@bors try @rust-timer queue

☀️ Try build successful (CI)
Build commit: 751817a (751817af04a05c150383439a06a40218fca7b666, parent: 397f93362974d298b79e0e0cd43677014aa7b722)

Finished benchmarking commit (751817a): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

Max RSS (memory usage)

Cycles

Binary size

Bootstrap: 467.607s -> 468.277s (0.14%)
Artifact size: 390.55 MiB -> 390.58 MiB (0.01%)

Nice! I think that was it.

r? @Kobzol

This tokio-rs/tracing#2553?

Looks like before if unset debug_assertions and set max_level_info was set, -> LevelFilter::INFO
but after pr it falls into LevelFilter::TRACE.

Great find!

Submitting pr, i hope tracing will be updated and we can directly bump it without workarounds.

I think that the behavior of tracing does actually correspond to what the documentation says (https://docs.rs/tracing/latest/tracing/level_filters/index.html) - note the "separately for release and debug builds" part. So either we held it wrong before, or their documentation changed in the meantime.

tokio-rs/tracing#3373, but need to test :-)

I think that in either case, we should just set both features, to be sure.

☔ The latest upstream changes (presumably #146267) made this pull request unmergeable. Please resolve the merge conflicts.