Pool ActiveQuerys in the query stack

[Veykril]

ActiveQuery is 192 bytes and has a couple of collections within it (2 of which are not extract) that we can potentially re-use the allocations for. So pooling those instead of creating, pushing and popping the query from the stack might be beneficial to perf.

Seems like we have small perf improvements.

Based on top of #626 (required for this)

[netlify]

✅ Deploy Preview for salsa-rs canceled.

Name	Link
🔨 Latest commit	f3f6cc4
🔍 Latest deploy log	https://app.netlify.com/sites/salsa-rs/deploys/67793ca987707e00089d5dfe

[codspeed-hq]

CodSpeed Performance Report

Merging #629 will not alter performance

_{Comparing Veykril:veykril/push-vznumyusmzww (f3f6cc4) with master (6c0dd82)}

Summary

✅ 9 untouched benchmarks

[MichaReiser]

Do you have any perf numbers from ra that confirm the improvement?

[Veykril]

Not yet hence why I am fine with waiting on these PRs until salsa can be used for r-a as is so its easier for me to test

[Veykril]

Huh that's odd, all I did was rebase on latest master and now we have a perf regression?

[Veykril]

okay locally I see (compared to #626:

• +2% on Mutating Inputs/new/InternedInput
• -10% on Mutating Inputs/amortized/InternedInput
• +19% on Mutating Inputs/new/Input
• -10% on Mutating Inputs/amortized/Input
• +9% on many_tracked_structs

[Veykril]

Looking at the profiling graph in codspeed this regressions to come from different allocation behavior (within unrelated code), so I don't think this is a direct regression?

[MichaReiser]

Codspeed can be flaky at times but 22% suggest that there's something wrong. The crossbeam_queue call now takes significantly longer... I think we should look into why

[Veykril]

It can be flaky but this report has been consistent across my 3 or so rebases earlier. My PR does change allocation patterns, so we might just be getting unlucky with the allocator here now. The SegQueue itself doesn't look special, it merely allocates in blocks of 31 items + pointer.

[Veykril]

Okay after fixing the benchmarks, this regression seems a lot more workable (and reasonable regarding my changes)

[Veykril]

Okay my latest drain changes are the culprit for that one. I do want to say that this PR will generally regress perf over our benches as none of them do multiple queries in succession (which is where this PR shines), they tend to do one or two which means this PR strictly does more allocation work than before.