Backtrace 0.3.68

[workingjubilee]

Uptakes these releases:

• https://github.com/rust-lang/backtrace-rs/releases/tag/0.3.68

r? @thomcc

[rustbot]

⚠️ Warning ⚠️

• These commits modify submodules.

[rustbot]

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.

[thomcc]

LGTM

[thomcc]

@bors r+

[bors]

📌 Commit 2150451 has been approved by thomcc

It is now in the queue for this repository.

[bors]

⌛ Testing commit 2150451 with merge 120598573092f2b9713914ed4e762758f9d81394...

[bors]

💔 Test failed - checks-actions

[thomcc]

@rustbot author

[workingjubilee]

I have no idea what's wrong.

[bors]

📌 Commit f9f5dbca6c3377a70dcbcd21bc7f4397dd879fa3 has been approved by thomcc

It is now in the queue for this repository.

[workingjubilee]

@bors p=5

[bors]

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

1. git checkout backtrace-0.3.68 (switch to your branch)
2. git fetch upstream master (retrieve the latest master)
3. git rebase upstream/master -p (rebase on top of it)
4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
5. git push self backtrace-0.3.68 --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message

Auto-merging library/std/Cargo.toml
Auto-merging Cargo.lock
CONFLICT (content): Merge conflict in Cargo.lock
Automatic merge failed; fix conflicts and then commit the result.

[workingjubilee]

Changes no longer include flate2 because that was seemingly taken up in #113046

Still removes a bunch of dupes: addr2line, miniz_oxide, and object!

@bors r=thomcc

[bors]

📌 Commit 079949d has been approved by thomcc

It is now in the queue for this repository.

[bors]

⌛ Testing commit 079949d with merge 571c9fc...

[bors]

☀️ Test successful - checks-actions
Approved by: thomcc
Pushing 571c9fc to master...

[rust-timer]

Finished benchmarking commit (571c9fc): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	2.2%	[1.8%, 2.6%]	12
Regressions ❌ (secondary)	1.6%	[0.3%, 6.8%]	38
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.1%	[-2.1%, -2.1%]	1
All ❌✅ (primary)	2.2%	[1.8%, 2.6%]	12

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	4.4%	[4.4%, 4.4%]	1
Regressions ❌ (secondary)	2.2%	[2.2%, 2.2%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.7%	[-3.7%, -3.7%]	1
All ❌✅ (primary)	4.4%	[4.4%, 4.4%]	1

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.8%	[1.5%, 2.2%]	12
Regressions ❌ (secondary)	1.7%	[0.8%, 5.9%]	21
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.8%	[1.5%, 2.2%]	12

Binary size

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	2.4%	[0.3%, 5.4%]	32
Regressions ❌ (secondary)	3.7%	[1.1%, 9.8%]	76
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.4%	[0.3%, 5.4%]	32

Bootstrap: 668.087s -> 667.216s (-0.13%)

[workingjubilee]

The only things I can think of in the backtrace crate which would so significantly alter performance would be the change to explicitly use mmap64, or the change to handle split dwarf. Otherwise I don't think it's directly related. I'll try to followup.

[thomcc]

It's a bit surprising since I wouldn't have expected backtraces to actually be computed in the compiler code that's relevant here.

[nnethercote]

Cachegrind diffs (e.g. here) might be informative.

[workingjubilee]

Okay, that actually does clarify things, but specifically it eliminates any hypotheses I had about anything specifically in the backtrace mattering, because I can't see anything from the backtrace crate active there, yet linking takes longer. So I think it's just about binary size.

Because backtrace goes into every binary, even slightly more to compile can be a hard hit. I think this time it might have been unavoidable, because if we're going to do a backtrace, and if we're going to use debug formats, we really want to be able to symbolicate with out-of-line data like split DWARF for... more or less the same reason that this was a perf hit. But I am going to keep an eye out for opportunities to reduce code size in that crate.

[workingjubilee]

I have opened rust-lang/backtrace-rs#541 as a first step towards addressing this in the future. Backtrace has probably been gradually racking up bloat over years. It may have good reasons to add more to our binary size in the future! So this should probably be treated as more of an ongoing problem that we need to attack with ongoing measures.