Unexpected performance impact from order of operands

[jokasimr]

Hi,

I'm experimenting a bit with pint in combination with Numpy and encountered a performance problem related to the order of operands in arithmetic operations with numpy arrays.

In [105]: a = np.linspace(-2, 2, 10_000)

In [106]: %timeit ureg.m * a
32.5 µs ± 346 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

In [107]: %timeit a * ureg.m
2.51 ms ± 12.1 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

Increasing the size of the array:

In [108]: a = np.linspace(-2, 2, 100_000)

In [109]: %timeit ureg.m * a
58.8 µs ± 85.1 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

In [110]: %timeit  a * ureg.m
24.1 ms ± 51.8 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)

Is this something that can be fixed or is there some good way to work around it?

Thanks for a very useful library!

[hgrecco]

Interesting. It would be nice to understand why and use it to our favour!

[jokasimr]

Yes, it would!

In this case, how does pint prevent ndarray.__mul__ from broadcasting the multiplication to every element?
Does it use __array_priority__ or something else?