Inline some Symbol functions

[Kobzol]

I noticed in some profiles that de-interning the symbols was relatively hot. I was trying to experiment with some sharding scheme, where the symbols would be split into N interners based on their first character, but I couldn't get it to work, probably due to some complexities around pre-interned 'static keywords and symbol comparison.

So I at least tried interning these two functions, which seems to produce very minor perf. gains on instruction counts.

r? @nnethercote

[Kobzol]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 10bfa0e (10bfa0ed88ae5b2c9d3c678818272ce0102097a4)
Base parent: f10db29 (f10db292a3733b5c67c8da8c7661195ff4b05774)

[rust-timer]

Finished benchmarking commit (10bfa0e): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing 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.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.2%, 0.3%]	3
Regressions ❌ (secondary)	0.1%	[0.0%, 0.2%]	2
Improvements ✅ (primary)	-0.3%	[-0.5%, -0.1%]	29
Improvements ✅ (secondary)	-0.4%	[-0.8%, -0.2%]	31
All ❌✅ (primary)	-0.3%	[-0.5%, 0.3%]	32

Max RSS (memory usage)

Results (primary 1.1%, secondary -0.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.0%	[3.0%, 3.0%]	1
Regressions ❌ (secondary)	3.1%	[3.1%, 3.1%]	1
Improvements ✅ (primary)	-0.9%	[-0.9%, -0.9%]	1
Improvements ✅ (secondary)	-2.9%	[-3.8%, -2.0%]	2
All ❌✅ (primary)	1.1%	[-0.9%, 3.0%]	2

Cycles

This perf run didn't have relevant results for this metric.

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 487.206s -> 488.197s (0.20%)
Artifact size: 388.97 MiB -> 389.06 MiB (0.02%)

[nnethercote]

@bors r+

[rust-bors]

📌 Commit 54955e5 has been approved by nnethercote

It is now in the queue for this repository.

[JonathanBrouwer]

@bors p=6 Scheduling this in front of the rollup so it has time to run try jobs

[rust-log-analyzer]

The job x86_64-gnu-nopt failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

test [debuginfo-gdb] tests/debuginfo/zst-interferes-with-prologue.rs ... ok

failures:

---- [debuginfo-gdb] tests/debuginfo/function-call.rs stdout ----
NOTE: compiletest thinks it is using GDB version 12001000
------gdb stdout------------------------------
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04.2) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Breakpoint 1 at 0x1b42: file /checkout/tests/debuginfo/function-call.rs, line 36.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, function_call::main () at /checkout/tests/debuginfo/function-call.rs:36
36     zzz(); // #break

------gdb stderr------------------------------
/checkout/obj/build/x86_64-unknown-linux-gnu/test/debuginfo/function-call.gdb/function-call.debugger.script:11: Error in sourced command file:
Couldn't write extended state status: Bad address.

------------------------------------------

error: gdb failed to execute
status: exit status: 1
command: PYTHONPATH="/checkout/src/etc" "/usr/bin/gdb" "-quiet" "-batch" "-nx" "-command=/checkout/obj/build/x86_64-unknown-linux-gnu/test/debuginfo/function-call.gdb/function-call.debugger.script"
--- stdout -------------------------------
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04.2) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Breakpoint 1 at 0x1b42: file /checkout/tests/debuginfo/function-call.rs, line 36.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, function_call::main () at /checkout/tests/debuginfo/function-call.rs:36
36     zzz(); // #break
------------------------------------------
--- stderr -------------------------------
/checkout/obj/build/x86_64-unknown-linux-gnu/test/debuginfo/function-call.gdb/function-call.debugger.script:11: Error in sourced command file:
Couldn't write extended state status: Bad address.
------------------------------------------

[rust-bors]

💔 Test for b53b79a failed: CI. Failed job:

• auto - x86_64-gnu-nopt (web logs, enhanced plaintext logs)

[Kobzol]

@bors retry flaky test

[rust-bors]

☀️ Test successful - CI
Approved by: nnethercote
Duration: 3h 12m 33s
Pushing af3d955 to main...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 3664b37 (parent) -> af3d955 (this PR)

Test differences

Show 2 test diffs

2 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard af3d95584dbddcae597890340995509a7fb47a50 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. x86_64-gnu-gcc: 38m 47s -> 1h 1m (+57.4%)
2. dist-loongarch64-musl: 1h 10m -> 1h 48m (+53.8%)
3. dist-x86_64-mingw: 1h 42m -> 2h 27m (+43.1%)
4. i686-msvc-2: 1h 31m -> 2h (+32.6%)
5. x86_64-gnu-gcc-core-tests: 6m 18s -> 8m 6s (+28.3%)
6. x86_64-msvc-1: 1h 55m -> 2h 27m (+27.8%)
7. i686-gnu-nopt-2: 2h 11m -> 1h 38m (-25.0%)
8. x86_64-gnu-llvm-21: 1h 14m -> 56m 14s (-24.7%)
9. x86_64-mingw-2: 2h 38m -> 1h 59m (-24.4%)
10. i686-gnu-2: 1h 13m -> 1h 26m (+18.1%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (af3d955): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

• If the regression was expected or you think it can be justified,
  please write a comment with sufficient written justification, and add
  @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
• If you think that you know of a way to resolve the regression, try to create
  a new PR with a fix for the regression.
• If you do not understand the regression or you think that it is just noise,
  you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
  were already notified of this PR).

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

Instruction count

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

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.2%, 0.3%]	4
Regressions ❌ (secondary)	0.1%	[0.1%, 0.2%]	2
Improvements ✅ (primary)	-0.3%	[-0.5%, -0.1%]	50
Improvements ✅ (secondary)	-0.4%	[-0.9%, -0.1%]	55
All ❌✅ (primary)	-0.3%	[-0.5%, 0.3%]	54

Max RSS (memory usage)

Results (primary 2.3%, secondary -6.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.3%	[2.3%, 2.3%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-6.2%	[-6.2%, -6.2%]	1
All ❌✅ (primary)	2.3%	[2.3%, 2.3%]	1

Cycles

Results (secondary -4.6%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.4%	[2.4%, 2.4%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-11.5%	[-11.5%, -11.5%]	1
All ❌✅ (primary)	-	-	0

Binary size

Results (primary 0.1%, secondary 0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.0%, 0.1%]	59
Regressions ❌ (secondary)	0.1%	[0.0%, 0.1%]	22
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.1%	[0.0%, 0.1%]	59

Bootstrap: 487.967s -> 488.74s (0.16%)
Artifact size: 388.37 MiB -> 389.01 MiB (0.17%)