refactor(perf): Pool ActiveQuerys in the query stack

[Veykril]

ActiveQuery is 192 bytes and has a couple of collections within it that we can potentially re-use the backing allocations for. So pooling those instead of creating, pushing and popping the query from the stack saves us from re-allocating unnecessarily in a bunch of cases.

[netlify]

✅ Deploy Preview for salsa-rs canceled.

Name	Link
🔨 Latest commit	59912e8
🔍 Latest deploy log	https://app.netlify.com/sites/salsa-rs/deploys/67d7f60c8b9b590008cbc9e1

[codspeed-hq]

CodSpeed Performance Report

Merging #629 will improve performances by 9.72%

_{Comparing Veykril:veykril/push-vznumyusmzww (59912e8) with master (d758691)}

Summary

⚡ 6 improvements
✅ 6 untouched benchmarks

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
⚡	new[Input]	11.4 µs	10.4 µs	+9.72%
⚡	new[SupertypeInput]	17.5 µs	16.3 µs	+7.33%
⚡	mutating[10]	14.7 µs	13.6 µs	+8.05%
⚡	mutating[20]	15 µs	13.9 µs	+7.92%
⚡	mutating[30]	15.1 µs	14 µs	+7.86%
⚡	converge_diverge	147.8 µs	142.6 µs	+3.63%

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

[Veykril]

The regression is a bit confusing to me, I can't quite interpret it. It shouldn't be an allocation as the stack ought to have enough size at that point from the setup. But overall this seems to have some nice reductions

[Veykril]

Alright figured out the cause of the regression, now its all green 🎉