PERF: regression in PeriodIndex getitem / get_loc

[jorisvandenbossche]

#41670 seems to have caused slowdowns in several of the Period indexing benchmarks: see https://pandas.pydata.org/speed/pandas/#regressions?sort=1&dir=desc, scrolldown to "2021-05-28 17:58"

One example: https://pandas.pydata.org/speed/pandas/#period.Indexing.time_get_loc?python=3.8&Cython=0.29.21&commits=ddc28a42

Originally posted by @jorisvandenbossche in #41670 (comment)

[jbrockmendel]

Looks like 90% of this is from the check isinstance(key, Period) and key.freq != self.freq. The rest I expect is in is_valid_na_for_dtype.

The key.freq != self.freq check is the hotspot. We can probably improve that quite a bit bc DateOffset.__eq__ checks some things that aren't relevant in this case. Really we just need to check that freq._period_dtype_code and freq.n match

[jbrockmendel]

idx = pd.period_range("2016-01-01", periods=10000)
key = idx[500]

%timeit idx.freq == key.freq
15.6 µs ± 112 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

%timeit idx.freq.n == key.freq.n and idx.freq._period_dtype_code == key.freq._period_dtype_code
893 ns ± 21.1 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

Just a question of where to implement this check

[jreback]

#42293 should fix, need to verify

[simonjayhawkins]

closing

(pandas-dev) simon@T3630:~/pandas/asv_bench (master)$ asv compare v1.3.0.dev0 master|grep period.Indexing.time_get_loc
      2.22±0.05μs      2.13±0.04μs     0.96  period.Indexing.time_get_loc