rustdoc: Cache `Attributes::doc_value` by camelid · Pull Request #153135 · rust-lang/rust

camelid · 2026-02-26T14:49:23Z

Locally, this appears to improve wall-time performance on the stm32f4
benchmark by about 2%. Also, it makes intuitive sense that we don't want
to recompute this over and over.

I also made the doc_strings field private since any modifications to
it will mean the doc_value_cache becomes stale.

This optimization was found with help from the Coz causal profiler.

r? @ghost

camelid · 2026-02-26T14:49:35Z

@bors try @rust-timer queue

rustdoc: Cache `Attributes::doc_value`

rust-bors · 2026-02-26T17:02:37Z

☀️ Try build successful (CI)
Build commit: 21552aa (21552aa0888670c728b749ebf695c115b3bfe9ec, parent: 69b78537fac74de40f009b076bcbbf54b77683ad)

rust-timer · 2026-02-26T20:04:08Z

Finished benchmarking commit (21552aa): 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)	0.3%	[0.3%, 0.3%]	2
Regressions ❌ (secondary)	0.2%	[0.1%, 0.3%]	14
Improvements ✅ (primary)	-0.4%	[-0.9%, -0.2%]	8
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.3%	[-0.9%, 0.3%]	10

Max RSS (memory usage)

Results (primary -0.5%, secondary 0.3%)

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

	mean	range	count
Regressions ❌ (primary)	2.0%	[0.9%, 5.0%]	4
Regressions ❌ (secondary)	4.2%	[4.2%, 4.2%]	1
Improvements ✅ (primary)	-10.3%	[-10.3%, -10.3%]	1
Improvements ✅ (secondary)	-3.6%	[-3.6%, -3.6%]	1
All ❌✅ (primary)	-0.5%	[-10.3%, 5.0%]	5

Cycles

Results (secondary 3.4%)

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)	3.4%	[2.1%, 4.6%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 480.132s -> 479.225s (-0.19%)
Artifact size: 395.80 MiB -> 395.83 MiB (0.01%)

Locally, this appears to improve wall-time performance on the stm32f4 benchmark by about 2%. Also, it makes intuitive sense that we don't want to recompute this over and over. I also made the `doc_strings` field private since any modifications to it will mean the `doc_value_cache` becomes stale.

camelid · 2026-02-27T02:09:57Z

r? rustdoc

camelid · 2026-02-27T02:11:03Z

Based on the results on the rustc-perf website, the improvements seem to outweigh the regressions. However, it might still make sense to check the code more carefully to see if there's a way to get this improvement without causing regressions.

camelid · 2026-02-27T02:41:33Z

@bors try @rust-timer queue

rustdoc: Cache `Attributes::doc_value`

It's now even smaller than before I added the `doc_value_cache` to `Attributes`. That's because in addition to boxing the cache field, I also converted `doc_strings` to be a `ThinVec` like the `other_attrs` field already is.

rust-bors · 2026-02-27T04:51:17Z

☀️ Try build successful (CI)
Build commit: ac5108a (ac5108ad2a49df4f02258ac9e43e4f78fe5c9383, parent: 6a979b3e32522049d0acb4a47f7ae44b7c8abfd5)

rust-timer · 2026-02-27T05:31:38Z

Finished benchmarking commit (ac5108a): 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)	0.5%	[0.3%, 0.8%]	5
Regressions ❌ (secondary)	0.6%	[0.2%, 0.8%]	23
Improvements ✅ (primary)	-0.4%	[-0.7%, -0.2%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.2%	[-0.7%, 0.8%]	8

Max RSS (memory usage)

Results (primary 2.0%, secondary -1.9%)

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

	mean	range	count
Regressions ❌ (primary)	2.0%	[0.8%, 4.4%]	5
Regressions ❌ (secondary)	3.8%	[3.8%, 3.8%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-7.6%	[-7.6%, -7.6%]	1
All ❌✅ (primary)	2.0%	[0.8%, 4.4%]	5

Cycles

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

Binary size

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

Bootstrap: 484.473s -> 480.37s (-0.85%)
Artifact size: 397.64 MiB -> 395.62 MiB (-0.51%)

GuillaumeGomez · 2026-02-27T13:40:06Z

It seems like the regressions outweight improvements a bit. Still seems like a good idea though. Do you have some leads for reducing the regressions already?

camelid · 2026-02-27T15:36:45Z

Hmm seems like it was better before I added the additional boxing. Although it could be just from the ThinVec change not from the doc value cache boxing.

rust-bors · 2026-03-09T17:08:18Z

☔ The latest upstream changes (presumably #153605) made this pull request unmergeable. Please resolve the merge conflicts.

rustbot added A-rustdoc-json Area: Rustdoc JSON backend S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Feb 26, 2026