CLN/PERF: group quantile

[mzeitlin11]

Inspired by idea from @jbrockmendel in #43489 (comment).

Didn't end up seeing a huge perf improvement though, for example results on a wide frame:

arr = np.random.randn(10 ** 5, 100)
df = pd.DataFrame(arr)
gb = df.groupby(df.index % 3)
gb.quantile(0.5)
# this pr: 1.18 s ± 9.58 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
# master: 1.55 s ± 10.1 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

Based on a quick profile, almost all time is spent in lexsort on master or with this pr - seems lexsorting the entire block at once has comparable performance to going column by column (I guess more improvement would show up on a really wide frame).

Regardless, though, I think moving this out of cython is an improvement (since gives no perf benefit for them to be in cython when just numpy functions, also saves ~80kb on compiled code).

[jbrockmendel]

why is the broadcast necessary here?

[mzeitlin11]

The problem was labels is 1-dimensional, but values can be 2. I couldn't figure out a way to make lexsort naturally broadcast in that case. I think this broadcast is relatively cheap, though, since np.broadcast_to uses views, so it shouldn't increase memory usage (and this op doesn't show up in a profile)

[jbrockmendel]

The broadcast itself is definitely cheap. In some cases I've later found that operations done on these broadcasted ndarrays are surprisingly slow. But if you've profiled it and its not an issue, then no complaints here.

[mzeitlin11]

Oh, interesting. The profile showed that all time is spent in lexsort, so definitely possible slow access on the broadcasted array is slowing it down. Will check how lexsort timing compares with this broadcast vs a contiguous array

[mzeitlin11]

Adding a copy after the broadcast doesn't seem to affect lexsort time in a profile

[jreback]

thanks @mzeitlin11