Use join_with_double_colon in write_shared.rs.

[nnethercote]

For consistency. Also, it's faster because join_with_double_colon does a better job estimating the allocation size than join from itertools.

r? @camelid

[nnethercote]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 0cf0f9f with merge ce461e1...

[bors]

☀️ Try build successful - checks-actions
Build commit: ce461e1 (ce461e11220b40294b00c3b70401b0b18c5aa088)

[rust-timer]

Finished benchmarking commit (ce461e1): 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.

	mean	range	count
Regressions ❌ (primary)	3.0%	[3.0%, 3.0%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.2%	[-3.9%, -0.6%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.5%	[-3.9%, 3.0%]	3

Max RSS (memory usage)

Results (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
Regressions ❌ (secondary)	4.9%	[4.9%, 4.9%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.3%	[-3.3%, -3.3%]	1
All ❌✅ (primary)	-	-	0

Cycles

Results (primary 0.4%, 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)	3.1%	[3.1%, 3.1%]	1
Regressions ❌ (secondary)	6.2%	[6.2%, 6.2%]	1
Improvements ✅ (primary)	-2.3%	[-2.3%, -2.3%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.4%	[-2.3%, 3.1%]	2

Binary size

Results (primary 1.1%)

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

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

Bootstrap: 691.157s -> 692.227s (0.15%)
Artifact size: 371.94 MiB -> 371.89 MiB (-0.01%)

[nnethercote]

If we restrict the perf results to just doc results we can see this is a win for typenum and nalgebra (which involve many type aliases) and everything else is affected negligibly. It's an echo of #141421.

r? @camelid

[lolbinarycat]

Even if itertools could use specialization, it probably still wouldn't be as good because we have specific knowledge of path sizes.

[camelid]

Awesome, thanks!

[camelid]

@bors r+

[bors]

📌 Commit 0cf0f9f has been approved by camelid

It is now in the queue for this repository.

[bors]

⌛ Testing commit 0cf0f9f with merge 45b80ac...

[bors]

☀️ Test successful - checks-actions
Approved by: camelid
Pushing 45b80ac to master...

[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 2783fc4 (parent) -> 45b80ac (this PR)

Test differences

Show 4 test diffs

4 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 45b80ac21a454d343833aad763ef604510c88375 --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-apple-2: 6068.2s -> 3510.0s (-42.2%)
2. aarch64-apple: 5344.5s -> 4072.5s (-23.8%)
3. dist-apple-various: 6602.1s -> 5136.2s (-22.2%)
4. dist-x86_64-apple: 9384.1s -> 11449.8s (22.0%)
5. pr-check-2: 2711.3s -> 2197.8s (-18.9%)
6. pr-check-1: 1864.3s -> 1565.3s (-16.0%)
7. x86_64-rust-for-linux: 2969.9s -> 2524.8s (-15.0%)
8. i686-gnu-2: 6314.0s -> 5371.3s (-14.9%)
9. i686-gnu-1: 8562.6s -> 7423.0s (-13.3%)
10. x86_64-gnu-llvm-19-1: 3861.6s -> 3361.8s (-12.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.