PERF: optimize is_numeric_v_string_like

[jorisvandenbossche]

In some of the arithmetic benchmarks (xref #39146 (comment)), just this is_numeric_v_string_like check takes up 15-35% of the overall time.

This improves the performance of this check by using some ndarray-specialized dtype checks (checking the kind instead of the generic functions):

In [1]: from pandas.core.dtypes.common import is_numeric_v_string_like

In [2]: arr = np.array([1, 2, 3])

In [3]: %timeit is_numeric_v_string_like(arr, 2.0)
2.3 µs ± 46.9 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)  # <-- master
482 ns ± 41.8 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)  # <-- PR

[jbrockmendel]

nice! two questions, neither blockers for this PR

1. IIUC this check exists to prevent a numpy-issued deprecation/future warning. Do we know when that ceases to be an issue?

2. Looks like is_string_like_dtype is only used in one other place (in dtypes.missing). lets just rip it out

[jorisvandenbossche]

Looks like is_string_like_dtype is only used in one other place (in dtypes.missing). lets just rip it out

Or I could update the helper function to what I used here, and then keep using it in those 3 places?

[jbrockmendel]

Or I could update the helper function to what I used here, and then keep using it in those 3 places?

either way i guess. i prefer to inline the check since i frequently find myself having to go look up what the is_foo_dtype's exact behavior is

[jorisvandenbossche]

OK, I am certainly fine with inlining here

[jorisvandenbossche]

IIUC this check exists to prevent a numpy-issued deprecation/future warning. Do we know when that ceases to be an issue?

Not directly an idea, but at least with the latest numpy release, you still get this wrong behaviour:

In [1]: np.array([1, 2]) == "a"
<ipython-input-1-c406769a5f40>:1: FutureWarning: elementwise comparison failed; returning scalar instead, but in the future will perform elementwise comparison
  np.array([1, 2]) == "a"
Out[1]: False

In [2]: np.__version__
Out[2]: '1.20.1'

so even if that would change in a next release, we are still going to need to workaround it for quite a while ..

[jbrockmendel]

LGTM