PERF: special case numpy.dtype in is_extension_array_dtype

[jorisvandenbossche]

Master:

dtype = np.dtype(float)
dtype2 = pd.Int32Dtype()

In [2]: %timeit pd.api.types.is_extension_array_dtype(dtype)
645 ns ± 59.1 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

In [3]: %timeit pd.api.types.is_extension_array_dtype(dtype2)
251 ns ± 9.68 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

with this branch, it keeps the speed for ExtensionDtype the same, and improves for numpy.dtype (avoiding a extension dtype registry lookup):

In [2]: %timeit pd.api.types.is_extension_array_dtype(dtype)
328 ns ± 24.3 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

In [2]:  %timeit pd.api.types.is_extension_array_dtype(dtype2)
240 ns ± 19.4 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

[jbrockmendel]

LGTM

[jreback]

sure (assume you found this from existing asvs), if not can you add the one from above.

[jreback]

also a whatsnew mention is prob worth it.

[jorisvandenbossche]

assume you found this from existing asvs, if not can you add the one from above.

Yes, it came from profiling the concat benchmarks (#39612), gives a small improvement. Now, apparently we don't have specific benchmarks for our dtype checks, so added one for is_extension_array_dtype (that could be supplemented with benchmarks for some of the other is_ checkers, but going to leave that for another issue/PR).

also a whatsnew mention is prob worth it.

Not sure it is worth it, this only gives a tiny improvement anywhere it is used (it was just lowing hanging fruit to shave off a percent, and with ArrayManager it gets used more, so getting more worth fixing it)

[jreback]

thanks @jorisvandenbossche