Flatten all -L search paths into a single list of files

[Kobzol]

View all comments

This is an optimization that mostly targets the new Cargo build dir layout.

Before, Cargo usually used to pass rustc a single -L path to a directory containing potentially a large number of .rlib or other dependency paths. Rustc is optimized for this, and does a preprocessing step, where it preloads all files from this directory into a sorted vector, in which it then performs binary search to look for files having a given prefix and postfix.

With the new build dir layout, this changes, and Cargo will pass potentially many (even hundreds, if your crate has many dependencies) -L directories, where each directory will usually have only 1-2 files. This is not ideal for the current rustc search implementation, because the old preprocessing isn't really worth it when the -L directory typically only has a single file, and because rustc will do a lot of work per each -L directory in the lookup phase, including some quadratic (O(n^2)) work.

With the large-workspace stress test from rustc-perf, where the final binary has ~1000 total and ~500 direct dependencies:

• With the old build dir layout, rustc does 4274 calls to FilesIndex::query
• With the new build dir layout, it does 1938314 calls to FilesIndex::query. Not ideal :)

This PR modifies the logic so that instead of going through all -L directories one by one when we are looking for a specific dependency, we pre-gather all files from all passed -L directories at the start, and sort them all together. Then, in the lookup phase, instead of performing <number of -L dirs> * 4 (.rmeta, .rlib, etc.) searched, we only perform the 4 searches across all files. This gets rid of the O(n^2) behavior.

Further improvements could be made, e.g. sort the files just once and then filter it for for both host and target filesearchs. I alsothought about pre-filtering the files further, e.g. based on their kind, but that is not worth it in usual situations, where ~all of the deps will be .rlibs or .rmetas anyway. What might work is pre-filtering based on their actual names (we strip known prefixes from them and then search based on the names alone, in a hashmap or something?), but that can be a follow-up.

Diff vs parent. of #159857: https://perf.rust-lang.org/compare.html?start=1a833e16546c2eb012758ddd499964fd8afee29e&end=6514e2707b7e90fecbc570eeaa36f3780a9b02b4&stat=instructions%3Au

[rustbot]

r? @mati865

rustbot has assigned @mati865.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 75 candidates
• Random selection from 21 candidates

[Kobzol]

Sorry, meant to open this as a draft, but missclicked.

r? @ghost

[petrochenkov]

This generally makes sense to me.

Cargo will pass potentially many (even hundreds, if your crate has many dependencies) -L directories

Was this considered by cargo team when the new build dir layout was designed? Why wasn't it considered an issue?

[Kobzol]

I'm sure that it was considered, though I don't know if there were any alternatives. CC @ranger-ross @epage if you have more context.

Recently we identified some optimizations that can be made to reduce that effect, they are being landed now (rust-lang/cargo#17168).

[epage]

Splitting rlibs into unique directories is fairly fundamental to the design. The trivial solution from there is hundreds of -Ls. I thought we had talked about performance implications but I can't find the thread and might be getting mixed up. We had acknowledged this will make Cargo's verbose output longer but we've already done that before with [lints] and --check-cfg so it seems less important to be careful about that. Maybe there are things we can further do (e.g. create a one off directory with symlinks to all of the rlibs) but we hadn't seen any concerns found during testing until we got to bootstrap recently and it seemed like those were being addressed.

[Kobzol]

I thought about the mega-symlink-dir approach too :) Might be interesting to try, as that might also have some performance implications.

I hope that with rust-lang/cargo#17168 and this PR landing and rust-lang/cargo#17183 being resolved, it will become workable, but we'll have to see how the new build dir layout works in practice to find out.

[Kobzol]

@bors try @rust-timer queue

[Kobzol]

@bors try parent=45bc0d28cc57296e36ef653a442e96367ba73d4a

[rust-bors]

☀️ Try build successful (CI)
Build commit: a31f58e (a31f58e2ea7fc54ca48521268b73b02ec9202b14)
Base parent: 45bc0d2 (45bc0d28cc57296e36ef653a442e96367ba73d4a)

[rust-timer]

Finished benchmarking commit (a31f58e): 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 rustc-perf
@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
Regressions ❌ (secondary)	0.5%	[0.4%, 0.7%]	7
Improvements ✅ (primary)	-1.3%	[-2.6%, -0.3%]	56
Improvements ✅ (secondary)	-7.5%	[-49.2%, -0.3%]	60
All ❌✅ (primary)	-1.3%	[-2.6%, -0.3%]	56

Max RSS (memory usage)

Results (primary -0.9%, secondary -0.8%)

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

	mean	range	count
Regressions ❌ (primary)	0.7%	[0.5%, 1.0%]	7
Regressions ❌ (secondary)	1.5%	[0.4%, 9.5%]	20
Improvements ✅ (primary)	-0.9%	[-2.8%, -0.4%]	121
Improvements ✅ (secondary)	-1.1%	[-5.4%, -0.4%]	178
All ❌✅ (primary)	-0.9%	[-2.8%, 1.0%]	128

Cycles

Results (primary -1.0%, secondary -2.3%)

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

	mean	range	count
Regressions ❌ (primary)	0.8%	[0.4%, 1.7%]	47
Regressions ❌ (secondary)	1.4%	[0.4%, 19.5%]	78
Improvements ✅ (primary)	-1.8%	[-5.8%, -0.4%]	109
Improvements ✅ (secondary)	-4.6%	[-32.3%, -0.4%]	130
All ❌✅ (primary)	-1.0%	[-5.8%, 1.7%]	156

Binary size

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

Bootstrap: 488.239s -> 487.438s (-0.16%)
Artifact size: 388.24 MiB -> 389.11 MiB (0.23%)

[Kobzol]

Thanks, applied the suggested changes.

@rustbot ready

[petrochenkov]

r=me after addressing #158823 (comment) and squashing commits.
@rustbot author

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[petrochenkov]

@bors r+

[rust-bors]

📌 Commit 55500ae has been approved by petrochenkov

It is now in the queue for this repository.

[rust-bors]

☀️ Test successful - CI
Approved by: petrochenkov
Duration: 3h 17m 34s
Pushing 6c04025 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 ad3d0bc (parent) -> 6c04025 (this PR)

Test differences

Show 1 test diff

Stage 2

• [run-make] tests/run-make/compressed-debuginfo-zstd: ignore (ignored if LLVM wasn't build with zstd for ELF section compression or LLVM is not the default codegen backend) -> pass (J0)

Job group index

• J0: x86_64-gnu-nopt

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 6c04025a8a1d2b4b25283bb56b6c6450e3d38ba7 --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-core-tests: 25m 44s -> 14m 3s (-45.4%)
2. x86_64-msvc-ext2: 1h 21m -> 1h 55m (+41.4%)
3. pr-check-1: 45m 41s -> 26m 57s (-41.0%)
4. dist-x86_64-solaris: 1h 16m -> 1h 43m (+35.9%)
5. x86_64-gnu-nopt: 2h 44m -> 1h 47m (-34.8%)
6. pr-check-2: 57m 23s -> 39m 19s (-31.5%)
7. x86_64-gnu-debug: 1h 39m -> 2h 10m (+30.7%)
8. dist-loongarch64-linux: 1h 28m -> 1h 55m (+30.0%)
9. x86_64-msvc-ext3: 1h 21m -> 1h 45m (+29.0%)
10. x86_64-rust-for-linux: 1h 7m -> 50m 51s (-24.9%)

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 (6c04025): 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.2%]	1
Regressions ❌ (secondary)	0.6%	[0.6%, 0.6%]	3
Improvements ✅ (primary)	-0.4%	[-0.6%, -0.2%]	14
Improvements ✅ (secondary)	-23.8%	[-49.2%, -0.1%]	17
All ❌✅ (primary)	-0.3%	[-0.6%, 0.2%]	15

Max RSS (memory usage)

Results (primary -1.2%, secondary -0.4%)

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

	mean	range	count
Regressions ❌ (primary)	1.0%	[0.9%, 1.1%]	2
Regressions ❌ (secondary)	4.3%	[2.1%, 6.2%]	5
Improvements ✅ (primary)	-1.7%	[-5.2%, -0.4%]	11
Improvements ✅ (secondary)	-1.5%	[-4.7%, -0.5%]	21
All ❌✅ (primary)	-1.2%	[-5.2%, 1.1%]	13

Cycles

Results (primary -0.4%, secondary -7.5%)

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

	mean	range	count
Regressions ❌ (primary)	0.7%	[0.4%, 0.9%]	5
Regressions ❌ (secondary)	1.9%	[0.6%, 4.1%]	7
Improvements ✅ (primary)	-0.8%	[-1.8%, -0.4%]	11
Improvements ✅ (secondary)	-9.9%	[-32.3%, -0.4%]	27
All ❌✅ (primary)	-0.4%	[-1.8%, 0.9%]	16

Binary size

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

Bootstrap: 495.641s -> 491.569s (-0.82%)
Artifact size: 391.11 MiB -> 390.31 MiB (-0.20%)