Proposed new feature or change:

np.interp takes a 1D list of scalars as an input y. When one wishes to interpolate multiple variables with the same basis/lookup points, np.interp() must be called repeatedly. The majority of the cost associated with this is the initial finding of what indexes should be looked at and the ratios of [n] and [n+1] required to get the interpolated value, so this is wasteful.

A toy example of the above:

In [1]: import numpy as np

In [2]: N = 10001
   ...: x = np.linspace(0, 1, N)
   ...: y1 = np.sort(np.random.normal(0, 1, N))
   ...: y2 = np.sort(np.random.uniform(0, 1, N))

In [3]: xr = np.random.random(1000000)

In [4]: %%timeit
   ...: y1i = np.interp(xr, x, y1)
   ...: y2i = np.interp(xr, x, y2)
   ...:
   ...:
131 ms ± 357 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)

In [5]: %%timeit
   ...: ycomplex = y1 + (complex(imag=1) * y2)
   ...: ycomplexi = np.interp(xr, x, ycomplex)
   ...: y1ic = np.real(ycomplexi)
   ...: y2ic = np.imag(ycomplexi)
   ...:
   ...:
65.3 ms ± 190 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)

By combining arrays y1 and y2 in to a complex number, interpolating that, then decomposing them, the same result is achieved in approximately half the time, indicating that the majority of the runtime arises from working out what indexes and ratios are required for each xp.

There are two issues with this:

1. It is limited to pairs of y vectors. In the event you have 1000 y vectors, there is still a ~500X speedup still on the table (assuming the limiting step as described above)
2. It is completely ridiculous, and anyone suggesting casting pairs of vectors to a complex number to speed up a production codebase will quite rightly be dismissed as having gone insane.

Both of these problems can be addressed by allowing the input for y to be an ndarray.