Could we defer to flox for GroupBy.first?

[max-sixty]

Is your feature request related to a problem?

I was wondering why a groupby("foo").first() call was going so slowly — I think we run a python loop for this, rather than calling into flox:

xarray/xarray/core/groupby.py

Lines 1218 to 1231 in b9780e7

	def _first_or_last(self, op, skipna, keep_attrs):
	if all(
	isinstance(maybe_slice, slice)
	and (maybe_slice.stop == maybe_slice.start + 1)
	for maybe_slice in self.encoded.group_indices
	):
	# NB. this is currently only used for reductions along an existing
	# dimension
	return self._obj
	if keep_attrs is None:
	keep_attrs = _get_keep_attrs(default=True)
	return self.reduce(
	op, dim=[self._group_dim], skipna=skipna, keep_attrs=keep_attrs
	)

Describe the solution you'd like

Could we call into flox? Numbagg has the routines...

Describe alternatives you've considered

No response

Additional context

No response

[dcherian]

Yes , the minor complication is that we should dispatch nanfirst and nanlast but not first, last. The latter are simply indexing using an indexer we already know, so the reduction approach is overkill.

Closing #8025 in favor of this one.

Out of curiosity how many groups does your problem have?

[max-sixty]

Sorry I missed #8025, I thought I searched; I guess first hit lots of unrelated issues and I missed it.

Out of curiosity how many groups does your problem have?

About 15K...

[dcherian]

About 15K...

Do you end up using dask for this, or just numbagg? Are these groups randomly distributed along the dimension, or are there patterns to how they are distributed (e.g. are they sequential)?

Just curious...

[max-sixty]

Do you end up using dask for this, or just numbagg?

I ended up just leaving it running for hours!

Are these groups randomly distributed along the dimension, or are there patterns to how they are distributed (e.g. are they sequential)?

Yes they're largely sequential!