Maximilian Roos

Interesting, and thanks for the quick response. I had been holding that `.reshape` is a view rather than a copy. But as you point out, that's not always the case....

We use the "new" form in https://github.com/numbagg/numbagg/pull/268, which is required to add additional scalar args such as `ddof`

This doesn't seem to be handling the output type correctly. I'll wait and see if there's progress on #9339, which would render this obsolete...

I can get the benchmarks in a better state so we can test this properly. `asv` should mostly work already, but I'm not sure it'll pick up on this sufficiently,...

So the surprising result is that it makes operations on small arrays (which don't parallelize) much faster, and has a small effect on functions on other arrays Here's the output...

> I pushed a commit to try initializing counts to 0 inside the inner loop. Does that make a difference? Unfortunately it doesn't budge at all. My guess is that...

> ping [numba/numba#2196](https://github.com/numba/numba/issues/2196)? Very possibly, nice find. Though that bottleneck performs similarly to us means it's a bit less likely to be an LLVM issue...

Nice! V interesting. So hopefully this will improve in future numba versions...

Is `.sum(dtype=foo)` equivalent to calling `.astype(foo)` on the input? On the result?

I see. I think this is possible, though not trivial — currently we have a [list of candidate signatures](https://github.com/numbagg/numbagg/blob/19de7e8664bd72c5cb707b03a31bf40e1ffa9865/numbagg/grouped.py#L13) which numba will JIT compile for. We could generate new ones...