hir_owner_parent optimized to inlined call for non-incremental build

[azhogin]

Continuation of #146880 and #147232.
'hir_owner_parent' query renamed 'hir_owner_parent_q'. hir_owner_parent inlined function added to optimize performance in case of non-incremental build.

'hir_owner_parent' query has low normalized average execution time (163ns) and good cache_hits (5773) according Daria's processed statistics. 'source_span', for comparison, has avg_ns_norm = 66ns and cache_hits = 11361.

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.

[Kobzol]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: f98c273 (f98c27362fe04fb22b3c3db681405edf9f642465, parent: 828c2a9afccf3b3ff8133368cfbc8bfe526aaa4d)

[azhogin]

r? @petrochenkov

[rustbot]

Requested reviewer is already assigned to this pull request.

Please choose another assignee.

[azhogin]

@rustbot ready

[rust-timer]

Finished benchmarking commit (f98c273): comparison URL.

Overall result: ✅ improvements - no action needed

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.

@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
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.5%	[-1.1%, -0.1%]	10
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -1.0%, secondary 0.2%)

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.3%	[2.2%, 2.3%]	2
Improvements ✅ (primary)	-1.0%	[-1.0%, -1.0%]	1
Improvements ✅ (secondary)	-1.9%	[-2.3%, -1.6%]	2
All ❌✅ (primary)	-1.0%	[-1.0%, -1.0%]	1

Cycles

Results (secondary 1.3%)

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)	5.3%	[5.3%, 5.3%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.7%	[-2.7%, -2.7%]	1
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 469.991s -> 471.779s (0.38%)
Artifact size: 388.38 MiB -> 388.40 MiB (0.01%)

[cjgillot]

You posted several PRs with this same idea. Instead of trying all queries, is there a way to address this structurally? I mean: change a macro in the query system to do this automatically?

[petrochenkov]

I mean: change a macro in the query system to do this automatically?

That was the plan if the optimization worked.
It didn't work previously, so this PR and #147388 were going to be the last two attempts, but it seems like in this case it may actually work.

[petrochenkov]

@azhogin
Could you write a bit of background in the PR descriptions? It's not just me who is reading them.
Mention that it's a continuation of #146880 and #147232, what is the idea behind the optimization, how is this query different from queries from the previous attempts, etc.

[petrochenkov]

but it seems like in this case it may actually work.

I wonder why it works though.
The logic inside the provider function doesn't look obviously cheaper than a query cache lookup.
And if it's actually cheaper, then why didn't the previous PRs work. Perhaps the hir_owner_parent query is just much hotter?

change a macro in the query system to do this automatically?

A drawback in this is that you'll probably need a function pointer, and it won't be possible to replace a query call with an inlined cheap function call.
In any case, adding a macro probably doesn't make sense until there are at least several queries on which this optimization works.

[petrochenkov]

r? @cjgillot to confirm that tcx.dep_graph.is_fully_enabled() is the right condition, and maybe answering to the comments above.

[azhogin]

@azhogin Could you write a bit of background in the PR descriptions?

Description improved. I have added top of processed query info table for minimal 'avg_ns_norm' in the description.

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[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]

Let's benchmark again to make sure the previous run wasn't a fluctuation.
@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 3b635d6 (3b635d6cc4215e4bb47485bac440f355a4245162, parent: 80b898258da78fdd1262438126aa0cf90e395f0c)

[rust-timer]

Finished benchmarking commit (3b635d6): 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.2%	[0.2%, 0.2%]	1
Regressions ❌ (secondary)	0.3%	[0.3%, 0.3%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.6%	[-1.2%, -0.1%]	8
All ❌✅ (primary)	0.2%	[0.2%, 0.2%]	1

Max RSS (memory usage)

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

Cycles

Results (secondary -2.7%)

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

Binary size

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

Bootstrap: 475.963s -> 475.656s (-0.06%)
Artifact size: 397.82 MiB -> 397.81 MiB (-0.00%)

[petrochenkov]

Still a minor improvement.

@bors r+ rollup=maybe
(Not worth blocking bors queue)

[rust-bors]

📌 Commit a5052a0 has been approved by petrochenkov

It is now in the queue for this repository.