PERF: enable caching on expensive offsets

[chris-b1]

xref #16463

We have a set of seemingly unused but also seemingly functional caching logic for generating ranges of offsets. Example

In [63]: BM = pd.offsets.BusinessMonthEnd()

In [64]: %timeit pd.date_range('1990-01-01', '2020-01-01', freq=BM)
18.1 ms ± 366 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [65]: BM._cacheable
Out[65]: False

In [66]: BM._cacheable = True

In [67]: %timeit pd.date_range('1990-01-01', '2020-01-01', freq=BM)
686 µs ± 17.2 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

In [68]: a = pd.date_range('1990-01-01', '2020-01-01', freq='BM')

In [69]: b = pd.date_range('1990-01-01', '2020-01-01', freq=BM)

In [70]: (a == b).all()
Out[70]: True

Possibly should enable or expose an API for this? Especially for slower offsets.

cc @jbrockmendel

[jbrockmendel]

The issue with caching DateOffset objects is that they are mutable. Most users will never tinker with them, but for the few who do, this could cause a lot of headaches. The medium-long term solution is to make DateOffsets immutable, then cache all of them. (Related: immutability will let us improve __hash__ 5-10x and __eq__/__ne__ by ~50x.)

There are a few more steps before we can implement immutability, but we recently got past a big roadblock with #17458. The current plan is to move the guts of tseries.offsets to _libs.tslibs.offsets and declare the relevant attributes cdef readonly. The attendant yak-shaving is moving forward with #17830, #17827, and #17746.

BTW there's also a CacheableOffset that AFAICT is unused.

I suppose in the interim enabling _cacheable for users who know what they're doing (or possibly making it the default and requiring users who want to tinker to change it?) is a viable option. Is that what you had in mind?

[jbrockmendel]

@chris-b1 offsets are now immutable; want to take a swing at this?

[jbrockmendel]

Closing as no-action since these are now all in cython, so should not be expensive. Can re-open if you want to revist.