Commit 809d9b72a05cc1f35bae1cf2865ec9ee19b11d2c

[github-actions]

Commit Range

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

• join_merge.ConcatIndexDtype.time_concat_series
  • dtype='datetime64[ns]', structure='monotonic', axis=1, sort=False - 256.426% (3.503ms)
• join_merge.ConcatIndexDtype.time_concat_series
  • dtype='datetime64[ns]', structure='monotonic', axis=1, sort=True - 248.283% (3.392ms)
• join_merge.JoinNonUnique.time_join_non_unique_equal - 985389.448% (706.838ms)
• timeseries.DatetimeIndex.time_unique
  • index_type='repeated' - 11.562% (60.664us)

[rhshadrach]

Haven't looked into the details here, but looks quite significant. cc @jbrockmendel

[jbrockmendel]

Looking at time_join_non_unique_equal, we are timing self.fracofday * self.temp. In main, these now have indexes with different units. I expect the perf hit is in alignment.

[rhshadrach]

I can put up a PR to adjust this benchmark so that it runs in less time.

[jbrockmendel]

two other (not mutually exclusive) options are a) patch DatetimeArray.equals with a fastpath for

if left[0] == right[0] and len(left) == len(right) and left.freq == right.freq and left.freq is not None: return True

b) change the default unit in PeriodArray.to_timestamp