Quantity.decompose() is slower than Quantity.to()

[abhisrkckl]

A while ago, I did a profiling run on PINT, and found that the performance issues of PINT arises from a large number of factors. One of the culprits was the frequent use of Quantity.decompose() function and Quantity.to() function with a string argument.

Here is a simple comparison:

%timeit (dmu*DMconst).decompose()

65.2 µs ± 798 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

%timeit (dmu*DMconst).to("Hz")

50.5 µs ± 495 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

%timeit (dmu*DMconst).to(u.Hz)

46 µs ± 274 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

In this case, decompose() is slower by 40%.

I think we should change decompose() to to() wherever possible.

[dlakaplan]

What about .to(...).value vs. .to_value(..)? Is there any difference?

[scottransom]

Optimizations with regards to units has come up multiple times in the past. This is a very good page to take a look at:
https://docs.astropy.org/en/stable/units/index.html#astropy-units-performance
Note especially how useful it is to define composite units once and also to apply them using the << operator rather than with a multiplication. Those cause multiple orders of magnitude speed improvements.

[abhisrkckl]

%timeit (dmu*DMconst).to_value(u.Hz)

43.6 µs ± 616 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

%timeit (dmu*DMconst).to_value("Hz")

47.4 µs ± 924 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

%timeit (dmu*DMconst).to(u.Hz).value

50.1 µs ± 2.71 µs per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

%timeit (dmu*DMconst).to("Hz").value

52.9 µs ± 971 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

About 20% difference between best and worst.

[dlakaplan]

So maybe the issue is that new code doesn't obey the optimizations that were already decided on. I don't see recommendations in the coding style doc.

[abhisrkckl]

So maybe the issue is that new code doesn't obey the optimizations that were already decided on.

I think this is the case. The various Unit conversion conventions are used liberally in the code. This is the case even in the case of core functionality like the TimingModel class.

[abhisrkckl]

Note especially how useful it is to define composite units once and also to apply them using the << operator rather than with a multiplication. Those cause multiple orders of magnitude speed improvements.

I tried this. There is significant difference in performance.