[DO NOT MERGE] perf run for only mul/add-reordering parts of #136095

[steffahn]

See #136095 (comment)

---

For good comparability with the performance of #136095, I'm keeping the rustc-hasher in rustc_type_ir at the "newly modified 2.*"… just noting this down in case it might be a difference from master that matters much.

---

(link to the rustc-hash commits for context)

[rustbot]

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

[rustbot]

rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead.

cc @rust-lang/rust-analyzer

rustdoc-json-types is a public (although nightly-only) API. If possible, consider changing src/librustdoc/json/conversions.rs; otherwise, make sure you bump the FORMAT_VERSION constant.

cc @CraftSpider, @aDotInTheVoid, @Enselic, @obi1kenobi

Some changes occurred in exhaustiveness checking

cc @Nadrieril

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.

[rust-log-analyzer]

The job mingw-check-tidy failed! Check out the build log: (web) (plain)

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

info: removing rustup binaries
info: rustup is uninstalled
##[group]Image checksum input
mingw-check-tidy
# We use the ghcr base image because ghcr doesn't have a rate limit
# and the mingw-check-tidy job doesn't cache docker images in CI.
FROM ghcr.io/rust-lang/ubuntu:22.04
ARG DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y --no-install-recommends \
  g++ \
  make \
---

COPY host-x86_64/mingw-check/validate-toolstate.sh /scripts/
COPY host-x86_64/mingw-check/validate-error-codes.sh /scripts/

# NOTE: intentionally uses python2 for x.py so we can test it still works.
# validate-toolstate only runs in our CI, so it's ok for it to only support python3.
ENV SCRIPT TIDY_PRINT_DIFF=1 python2.7 ../x.py test \
           --stage 0 src/tools/tidy tidyselftest --extra-checks=py,cpp
# This file is autogenerated by pip-compile with Python 3.10
# by the following command:
#
#    pip-compile --allow-unsafe --generate-hashes reuse-requirements.in
---
#12 2.691 Building wheels for collected packages: reuse
#12 2.692   Building wheel for reuse (pyproject.toml): started
#12 2.900   Building wheel for reuse (pyproject.toml): finished with status 'done'
#12 2.901   Created wheel for reuse: filename=reuse-4.0.3-cp310-cp310-manylinux_2_35_x86_64.whl size=132719 sha256=be6760d5849de4a58bbe52b85ca57a55f2b32b518b17029a5ad2e530db0d4303
#12 2.901   Stored in directory: /tmp/pip-ephem-wheel-cache-fg7nq295/wheels/3d/8d/0a/e0fc6aba4494b28a967ab5eaf951c121d9c677958714e34532
#12 2.904 Installing collected packages: boolean-py, binaryornot, tomlkit, reuse, python-debian, markupsafe, license-expression, jinja2, chardet, attrs
#12 3.296 Successfully installed attrs-23.2.0 binaryornot-0.4.4 boolean-py-4.0 chardet-5.2.0 jinja2-3.1.4 license-expression-30.3.0 markupsafe-2.1.5 python-debian-0.1.49 reuse-4.0.3 tomlkit-0.13.0
#12 3.296 WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
#12 3.820 Collecting virtualenv
#12 3.820 Collecting virtualenv
#12 3.859   Downloading virtualenv-20.29.1-py3-none-any.whl (4.3 MB)
#12 3.966      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4.3/4.3 MB 40.6 MB/s eta 0:00:00
#12 4.007 Collecting distlib<1,>=0.3.7
#12 4.034   Downloading distlib-0.3.9-py2.py3-none-any.whl (468 kB)
#12 4.042      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 469.0/469.0 KB 69.8 MB/s eta 0:00:00
#12 4.076 Collecting platformdirs<5,>=3.9.1
#12 4.079   Downloading platformdirs-4.3.6-py3-none-any.whl (18 kB)
#12 4.113 Collecting filelock<4,>=3.12.2
#12 4.117   Downloading filelock-3.17.0-py3-none-any.whl (16 kB)
#12 4.198 Installing collected packages: distlib, platformdirs, filelock, virtualenv
#12 4.383 Successfully installed distlib-0.3.9 filelock-3.17.0 platformdirs-4.3.6 virtualenv-20.29.1
#12 DONE 4.5s

#13 [7/8] COPY host-x86_64/mingw-check/validate-toolstate.sh /scripts/
#13 DONE 0.0s
---
DirectMap4k:      114624 kB
DirectMap2M:     6176768 kB
DirectMap1G:    12582912 kB
##[endgroup]
Executing TIDY_PRINT_DIFF=1 python2.7 ../x.py test            --stage 0 src/tools/tidy tidyselftest --extra-checks=py,cpp
+ TIDY_PRINT_DIFF=1 python2.7 ../x.py test --stage 0 src/tools/tidy tidyselftest --extra-checks=py,cpp
    Finished `dev` profile [unoptimized] target(s) in 0.05s
##[endgroup]
WARN: currently no CI rustc builds have rustc debug assertions enabled. Please either set `rust.debug-assertions` to `false` if you want to use download CI rustc or set `rust.download-rustc` to `false`.
downloading https://static.rust-lang.org/dist/2025-01-08/rustfmt-nightly-x86_64-unknown-linux-gnu.tar.xz
---
   Compiling ignore v0.4.23
   Compiling fluent-syntax v0.11.1
   Compiling build_helper v0.1.0 (/checkout/src/build_helper)
   Compiling regex v1.11.1
   Compiling rustc-hash v2.2.0 (https://github.com/steffahn/rustc-hash?rev=1028035a81ec84e9fe25e39daeccb9d9ff7245d8#1028035a)
   Compiling similar v2.6.0
   Compiling termcolor v1.4.1
   Compiling tidy v0.1.0 (/checkout/src/tools/tidy)
    Finished `release` profile [optimized] target(s) in 30.32s
    Finished `release` profile [optimized] target(s) in 30.32s
##[endgroup]
fmt check
fmt: checked 5812 files
tidy check
tidy error: invalid source: "git+https://github.com/steffahn/rustc-hash?rev=1028035a81ec84e9fe25e39daeccb9d9ff7245d8#1028035a81ec84e9fe25e39daeccb9d9ff7245d8"

thread 'deps (.)' panicked at src/tools/tidy/src/deps.rs:590:24:
cmd.exec() failed with `cargo metadata` exited with an error:     Updating crates.io index
    Updating git repository `https://github.com/steffahn/rustc-hash`
error: the lock file /checkout/src/tools/rust-analyzer/Cargo.lock needs to be updated but --locked was passed to prevent this
If you want to try to generate the lock file without accessing the network, remove the --locked flag and use --offline instead.
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

thread 'main' panicked at src/tools/tidy/src/main.rs:60:49:
called `Result::unwrap()` on an `Err` value: Any { .. }
called `Result::unwrap()` on an `Err` value: Any { .. }
Command has failed. Rerun with -v to see more details.
  local time: Sun Jan 26 22:01:46 UTC 2025
  network time: Sun, 26 Jan 2025 22:01:46 GMT
##[error]Process completed with exit code 1.
Post job cleanup.

[thomcc]

@bors try @rust-timer queue

[bors]

⌛ Trying commit c812d70 with merge c48f26f...

[lqd]

I'm not sure this'd fix the collisions issue in v2 🤔. I guess we can wait for perf but maybe you can also try it on the dataset from the issue.

[steffahn]

@lqd The point of this is the inverse; to see if the re-ordering part of the collisions fix was part of the performance-regression in #136095

this PR doesn't solve anything, but the goal is to get a better understanding & rule out potential oversights or misinterpretations, regarding the regressed performance observable in #136095's perf-run

---

The collision fix used in #136095 kind-of requires the re-ordering trick anyway (if you don't want to spend time on an additional multiplication).

This also means: In case it does turn out very relevant, such a potential insight of "the re-ordering was the problem" doesn't give any immediate solutions; but at least it could help avoid spending time&focus on the wrong details.

[lqd]

I see, ok.

[bors]

☀️ Try build successful - checks-actions
Build commit: c48f26f (c48f26f7c8b5edd81324f97539cdd20a39a145ed)

[rust-timer]

Finished benchmarking commit (c48f26f): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

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

Instruction count

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

Max RSS (memory usage)

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

Cycles

Results (secondary 1.7%)

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)	-	-	0
Regressions ❌ (secondary)	1.7%	[1.2%, 2.2%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 773.224s -> 772.081s (-0.15%)
Artifact size: 328.21 MiB -> 328.14 MiB (-0.02%)

[steffahn]

Good, this seems to confirm that there are no performance problems from the reordering, so it's indeed alright to just focus on the performance of the finalizer, in any potential variants of #136095 :-)