Potential regression induced by PR #57445

[rhshadrach]

PR #57445 may have induced a performance regression. If it was a necessary behavior change, this may have been expected and everything is okay.

Please check the links below. If any ASVs are parameterized, the combinations of parameters that a regression has been detected for appear as subbullets.

• frame_methods.SortValues.time_frame_sort_values
  • ascending=False
  • ascending=True
• gil.ParallelGroups.time_get_groups
  • threads=2
  • threads=4
  • threads=8
• groupby.Groups.time_series_groups
  • key='int64_large'
  • key='int64_small'
  • key='object_large'
  • key='object_small'
• indexing.ChainIndexing.time_chained_indexing
  • mode='warn'
  • mode=None
• indexing.NumericSeriesIndexing.time_getitem_array
  • dtype=<class 'numpy.int64'>; index_structure='unique_monotonic_inc'
• indexing.NumericSeriesIndexing.time_iloc_array
  • dtype=<class 'numpy.int64'>; index_structure='unique_monotonic_inc'
• indexing.NumericSeriesIndexing.time_loc_array
  • dtype=<class 'numpy.int64'>; index_structure='unique_monotonic_inc'
• reshape.ReshapeMaskedArrayDtype.time_stack
  • dtype='Float64'
  • dtype='Int64'

Subsequent benchmarks may have skipped some commits. The link below lists the commits that are between the two benchmark runs where the regression was identified.

Commit Range

cc @mroeschke

[rhshadrach]

@mroeschke - I've checked off the regressions where there are already fixes in place.

[mroeschke]

Thanks!

[mroeschke]

I think these are also mostly expected. There's a tradeoff here of doing More Work to potentially save memory in the resulting object.

Also in terms of milestoning this issue (and others), if the original PR was targeted for 3.0 shouldn't this issue milestone also be 3.0?

[rhshadrach]

Makes sense on both counts, should have been milestoned as 3.0.