rustdoc: Cache Attributes::doc_value

[camelid]

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]

@bors try @rust-timer queue

[rust-bors]

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

[rust-timer]

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%)

[camelid]

r? rustdoc

[camelid]

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]

@bors try @rust-timer queue

[rust-bors]

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

[rust-timer]

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]

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]

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.