is_freeze/unpin/async_drop: use query cache for large tuples#156902
is_freeze/unpin/async_drop: use query cache for large tuples#156902RalfJung wants to merge 1 commit into
Conversation
|
@bors try |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
is_freeze/unpin/async_drop: use query cache for large tuples
|
@bors try |
This comment has been minimized.
This comment has been minimized.
is_freeze/unpin/async_drop: use query cache for large tuples
|
The job Click to see the possible cause of the failure (guessed by this bot) |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (d358d34): comparison URL. Overall result: ❌ regressions - please read:Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf. Next, please: If you can, justify the regressions found in this try perf run in writing along with @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 (primary 0.4%, secondary -2.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -2.3%, secondary 2.5%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 509.684s -> 510.384s (0.14%) |
I'm a bit surprised that we're not using the cache for large tuples as those could be expensive to re-visit again and again.