Make QuickerSort efficient for non-homogonous eltype

[LilithHafner]

Set v[j] = pivot in partition! rather than returning pivot to caller to make partition! type stable for non-concrete eltype

This is intended to address the regression in master vs 1.8 revealed by nanosoldier

["union", "array", ("sort", "Union{Nothing, Bool}", 0)]	1.37 (5%) ❌	3.01 (1%) ❌

[link to motivating benchmark results]

[LilithHafner]

@nanosoldier runbenchmarks("sort", vs=":master")
@nanosoldier runbenchmarks("sort", vs=":release-1.8") [did not run]

[nanosoldier]

Your benchmark job has completed - no performance regressions were detected. A full report can be found here.

[LilithHafner]

@nanosoldier runbenchmarks("sort", vs=":release-1.8")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

[LilithHafner]

Much better, though still not perfect

["union", "array", ("sort", "Union{Nothing, Bool}", 0)]	1.00 (5%)	1.33 (1%) ❌

With this and #47966 I believe all the BaseBenchmark regressions in runtime will be gone, though regressions in allocations will remain & some will not correspond to compensating improvements in runtime. Further, using JuliaCI/BaseBenchmarks.jl#305 will also likely still show real regressions. I'll keep looking for regressions once this and #47966 merge.

I'll post here when I get the benchmark results from running JuliaCI/BaseBenchmarks.jl#305 locally across this PR.

[LilithHafner]

Local tests reveal no regressions & memory improvements for "mixed eltype with by order"

[LilithHafner]

Bump. I think this is ready to go. The remaining more minor regression is likely due to a different underlying cause. I'll probably merge it in a couple of days if there are no objections

[LilithHafner]

This is orthogonal to #47966 so I'm not concerned about semantic merge conflicts

[LilithHafner]

Running nanosoldier here to search for possible remaining regressions to fix before we release 1.9

@nanosoldier runbenchmarks("sort" vs=":release-1.8")

[LilithHafner]

@nanosoldier runbenchmarks("sort", vs=":release-1.8")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

[StefanKarpinski]

Is QuickerSort what you ended up calling your stable quicksort algorithm?

[LilithHafner]

Yes (reasoning); it is probably not too late to rename it if you have a better idea. (nobody seems to be using it by name)

[StefanKarpinski]

I think calling it StableQuickSort would be a slightly less loaded choice, but I see you address that there. If I'm understanding the reasoning, it's that your modified quicksort is stable in its current form but could be modified to be still out of place but unstable and would do less work in that form, so there's a potential for a faster unstable variation of it, which would make the name "StableQuickSort" confusing. Is that correct?

[LilithHafner]

Precisely.

[StefanKarpinski]

I still think StableQuickSort would be ok since the most common version would be stable (you can almost always make something unstable somehow). Or maybe QuickBufferSort? But QuickerSort is ok too I guess.

[LilithHafner]

I prefer QuickBufferSort over StableQuickSort. I don't feel strongly either way between QuickBufferSort (proposed) and QuickerSort (current). If you or others feel strongly enough to rename it, I'd be happy to make a PR. It should be technically trivial.