Get rid of QueryVTable::call_query_method_fn#153387
Get rid of QueryVTable::call_query_method_fn#153387Zalathar wants to merge 1 commit intorust-lang:mainfrom
QueryVTable::call_query_method_fn#153387Conversation
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Get rid of `QueryVTable::call_query_method_fn`
|
Seems fine, good to get rid of this fn. r=me once perf results come back ok. |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (5bc0460): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking 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 Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (secondary -5.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.4%, secondary -2.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.1%, secondary 0.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 481.183s -> 478.983s (-0.46%) |
|
@bors r=nnethercote |
This comment has been minimized.
This comment has been minimized.
Calling the query method is equivalent to doing a cache lookup and then calling `execute_query_fn`, so we can just do that manually instead.
|
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. |
|
Rebased. @bors r=nnethercote |
Calling the query method to promote a value is equivalent to doing a cache lookup and then calling
execute_query_fn, so we can just do that manually instead.There are two “functional” differences here: If a cache hit occurs, we don't record the hit for self-profiling, and we don't register a read of the dep node. In the context of promotion, which touches all eligible cache entries just before writing the memory-cached values to disk, those two steps should be unnecessary overhead anyway.
r? nnethercote (or compiler)