is_doc_hidden optimized to hook in case of non-incremental build

[azhogin]

Continuation of #146880, #147232 and #147387.

'is_doc_hidden' query renamed 'is_doc_hidden_q'. is_doc_hidden hook added to optimize performance in case of non-incremental build.

Optimization may be profitable for queries with low normalized average execution time (to replace cache lookup into inlined call) and be significant with good cache_hits.

Query	cache_hits	min_ns	max_ns	avg_ns_norm
source_span	11361	18	2991	66
hir_owner_parent	5773	52	1773	163
*is_doc_hidden*	3134	47	1111	285
lookup_deprecation_entry	13905	36	6208	287
object_lifetime_default	5840	63	4688	290
upvars_mentioned	2575	75	7722	322
intrinsic_raw	21235	73	3453	367

Draft PR to measure performance changes.

[azhogin]

r? @petrochenkov

[petrochenkov]

@bors2 try @rust-timer queue

[Kobzol]

Is there a way to "automate" this? E.g. annotate queries for which we know/think that they are not worth it in non-incremental builds, and then make the query infra automatically turn them into hooks. It seems a bit silly to manually create this query/hook split for many individual queries..

[rust-bors]

☀️ Try build successful (CI)
Build commit: 81ee3ee (81ee3ee74d4cf4fc13131bdfe90d85b92480fb17, parent: bd3487101ff9397ca8a54dd83aa360d93342b82e)

[petrochenkov]

@Kobzol

Is there a way to "automate" this? E.g. annotate queries for which we know/think that they are not worth it in non-incremental builds, and then make the query infra automatically turn them into hooks. It seems a bit silly to manually create this query/hook split for many individual queries..

#147387 (comment) (and below)

[rust-timer]

Finished benchmarking commit (81ee3ee): 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)	1.1%	[0.4%, 1.9%]	3
Regressions ❌ (secondary)	0.5%	[0.1%, 0.6%]	4
Improvements ✅ (primary)	-0.5%	[-1.3%, -0.2%]	12
Improvements ✅ (secondary)	-0.8%	[-1.3%, -0.1%]	27
All ❌✅ (primary)	-0.2%	[-1.3%, 1.9%]	15

Max RSS (memory usage)

Results (secondary -1.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)	1.0%	[1.0%, 1.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.2%	[-2.5%, -1.7%]	3
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary -3.0%)

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)	2.1%	[2.1%, 2.1%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.7%	[-6.5%, -2.3%]	8
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 474.495s -> 473.612s (-0.19%)
Artifact size: 388.40 MiB -> 388.41 MiB (0.00%)

[petrochenkov]

Yep, improvements on rustdoc.
It shows that

• The optimization makes sense in general, you can do better than the query cache lookup, but it requires the query to be quite hot to notice the difference.
• The decision to perform or not to perform the optimization should be done separately for local and extern queries.

[petrochenkov]

I'll wait until @cjgillot answers on #147387.
@rustbot blocked