Improve speed in projections/geo.py #22677

oscargus · 2022-03-20T16:16:25Z

PR Summary

Stumbled upon some optimization opportunities while browsing the code.

Removed redundant calls to sin/cos/sqrt. Replaced np.sqrt with power computation for constant scalars. Used np.cbrt.

In [41]: %timeit np.sqrt(2.0)
1.16 µs ± 9.11 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)

In [42]: %timeit math.sqrt(2.0)
77.1 ns ± 0.214 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)

PR Checklist

Tests and Styling

Has pytest style unit tests (and pytest passes).
Is Flake 8 compliant (install flake8-docstrings and run flake8 --docstring-convention=all).

Documentation

New features are documented, with examples if plot related.
New features have an entry in doc/users/next_whats_new/ (follow instructions in README.rst there).
API changes documented in doc/api/next_api_changes/ (follow instructions in README.rst there).
Documentation is sphinx and numpydoc compliant (the docs should build without error).

lib/matplotlib/projections/geo.py

timhoffm · 2022-03-21T10:34:25Z

+/-0 on this:

disadvantage: mixing np and math makes the code more complex
advantage: performance gain

The question is: How much performance gain do we get? E.g if I save 1µs in a function that takes 100µs (numbers made up), special-casing some functions to math is IMHO not worth it.

oscargus · 2022-03-21T10:48:12Z

Note that math.sqrt is no longer used. The math.pi part was not originally part of the PR, but suggested by @anntzer

New benchmark (different computer):

In [45]: %timeit np.sqrt(2)
717 ns ± 2.49 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)

In [46]: %timeit 2 ** (1 / 2)
5.97 ns ± 0.376 ns per loop (mean ± std. dev. of 7 runs, 100,000,000 loops each)

Not sure how much math.pi improves the speed (if any). Tried to read up if the compiler possibly can precompute the result with math.pi but I have not come to any insight.

I'm also a bit doubtful about if e.g. pi / 2 or pi / 2.0 should be used (or 0.5 * pi). Benchmarking gives a slight advantage for the float constants, but there may be other aspects as well.

oscargus · 2022-03-21T10:56:33Z

For reference, in current main:

/ 2 : 363 instances (a few are comments/docstring etc)
/ 2. : 107 (all proper code)
* 0.5 : 41 (all proper code)
0.5 * : 67 (some overlap with * 0.5)

anntzer · 2022-03-21T15:05:05Z

The question is not how much speed is gained by replacing np.sqrt(2) by 2**(1/2), but how much is gained e.g. when creating a minimal geo axes or plotting something on a geo axes or whatever "minimal matplotlib-relevant action" that exercises this piece of code.

oscargus · 2022-03-21T15:35:01Z

The question is not how much speed is gained by replacing np.sqrt(2) by 2**(1/2)

Correct. But much easier to just try out the operation...

oscargus · 2022-03-21T15:35:43Z

Btw, it seems like not all the code is actually tested. I messed up in a trig rewrite in two locations, but only got an error for one of them...

timhoffm · 2022-03-21T21:51:58Z

Btw, it seems like not all the code is actually tested.

codecov states that we have 81% coverage. The missing 19% is unfortunately not only edge cases and trivial code. In particular in earlier times, testing was more optional, and there's quite a bit of code that nobody has written tests for yet.

On the optimizations: I have the impression you are falling for the micro-optimization trap

In [45]: %timeit np.sqrt(2)
717 ns ± 2.49 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)

In [46]: %timeit 2 ** (1 / 2)
5.97 ns ± 0.376 ns per loop (mean ± std. dev. of 7 runs, 100,000,000 loops each)

In relative numbers this is a magnificently sounding 100x speed improvement. However, assume we need 100 of those calculations for creating a plot. That's still only 70us, and negligable compared to

In [4]: %%timeit
...: plt.plot([1, 2])
...: plt.show(block=False)
...: plt.close()
...:
26.4 ms ± 1.44 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)

Unless such nanosecond optimizations are in a really hot place, they don't give any measurable benefit and are thus not worth the effort. Even more: If the performance benefit is negligable, other aspects like readability and maintainability of the code will become the deciding factors how code is best written.

tacaswell · 2022-03-22T03:24:51Z

In particular in earlier times, testing was more optional, and there's quite a bit of code that nobody has written tests for yet.

We are older than both pytest and nose ;)

timhoffm · 2022-03-22T07:57:31Z

We are older than both pytest and nose ;)

If somebody still knows nose 👴.

anntzer · 2022-03-23T10:01:20Z

lib/matplotlib/projections/geo.py

            alpha = np.sqrt(1.0 + cos_latitude * np.cos(half_long))
-            x = (2.0 * sqrt2) * (cos_latitude * np.sin(half_long)) / alpha
+            x = (2 * sqrt2) * (cos_latitude * np.sin(half_long)) / alpha


I'd just write 2**(3/2) here and 2**(1/2) below and drop the sqrt(2) variable, as noticed elsewhere this will get inlined anyways.

I follow the argument in #22678 (comment) that 2**0.5 reads better than 2**(1/2).

That's fine with me too.

anntzer · 2022-03-23T10:02:46Z

lib/matplotlib/projections/geo.py

@@ -351,18 +352,18 @@ def transform_non_affine(self, ll):
            # docstring inherited
            def d(theta):
                delta = (-(theta + np.sin(theta) - pi_sin_l)
-                         / (1 + np.cos(theta)))
+                         / (1.0 + np.cos(theta)))


Let's stick with 1 (and likewise 2 for 2.0 below) unless it matters significantly (I doubt so...); it reads better IMO (e.g. it matches the math formula).

anntzer · 2022-03-23T10:04:28Z

lib/matplotlib/projections/geo.py

-            latitude = np.arcsin((2 * theta + np.sin(2 * theta)) / np.pi)
+            sqrt2 = 2 ** (1 / 2)
+            theta = np.arcsin(y / sqrt2)
+            longitude = (math.pi / (2.0 * sqrt2)) * x / np.cos(theta)


again sqrt2 doesn't warrant being a separate variable; the compiler will inline 2**(1/2) in theta and 2**(3/2) in longitude; and again 2.0 -> 2

anntzer · 2022-04-24T21:49:12Z

lib/matplotlib/projections/geo.py

@@ -52,8 +53,8 @@ def cla(self):

        self.grid(rcParams['axes.grid'])

-        Axes.set_xlim(self, -np.pi, np.pi)
-        Axes.set_ylim(self, -np.pi / 2.0, np.pi / 2.0)
+        Axes.set_xlim(self, -math.pi, math.pi)


You can just use np.pi in most of these places, because set_xlim/etc. will directly convert everything to numpy scalars anyways, obviating any speedup. (Using python scalars is only useful if you do some computations with them, and even then, probably the gain of writing math.pi*2 below is obviated by the additional builtin->numpy conversion.)

jklymak · 2023-01-26T02:19:04Z

@oscargus did you still want this to move forward? I'll move to draft, but feel free to move back

oscargus added the Performance label Mar 20, 2022

oscargus force-pushed the geospeedup branch from 51473c2 to 33f6e26 Compare March 20, 2022 16:18

oscargus commented Mar 20, 2022

View reviewed changes

lib/matplotlib/projections/geo.py Outdated Show resolved Hide resolved

anntzer reviewed Mar 20, 2022

View reviewed changes

lib/matplotlib/projections/geo.py Outdated Show resolved Hide resolved

anntzer reviewed Mar 20, 2022

View reviewed changes

lib/matplotlib/projections/geo.py Outdated Show resolved Hide resolved

oscargus force-pushed the geospeedup branch 4 times, most recently from 9602112 to af48923 Compare March 20, 2022 23:12

Improve speed

9afe772

oscargus force-pushed the geospeedup branch from af48923 to 9afe772 Compare March 21, 2022 09:21

anntzer reviewed Mar 23, 2022

View reviewed changes

anntzer reviewed Apr 24, 2022

View reviewed changes

jklymak marked this pull request as draft January 26, 2023 02:19

github-actions bot added the status: needs rebase label Apr 6, 2023

Uh oh!

Improve speed in projections/geo.py #22677

Are you sure you want to change the base?

Improve speed in projections/geo.py #22677

Uh oh!

Conversation

oscargus commented Mar 20, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Summary

PR Checklist

Uh oh!

Uh oh!

Uh oh!

Uh oh!

timhoffm commented Mar 21, 2022

Uh oh!

oscargus commented Mar 21, 2022

Uh oh!

oscargus commented Mar 21, 2022

Uh oh!

anntzer commented Mar 21, 2022

Uh oh!

oscargus commented Mar 21, 2022

Uh oh!

oscargus commented Mar 21, 2022

Uh oh!

timhoffm commented Mar 21, 2022

Uh oh!

tacaswell commented Mar 22, 2022

Uh oh!

timhoffm commented Mar 22, 2022

Uh oh!

anntzer Mar 23, 2022

Choose a reason for hiding this comment

Uh oh!

timhoffm Mar 23, 2022

Choose a reason for hiding this comment

Uh oh!

anntzer Mar 23, 2022

Choose a reason for hiding this comment

Uh oh!

anntzer Mar 23, 2022

Choose a reason for hiding this comment

Uh oh!

anntzer Mar 23, 2022

Choose a reason for hiding this comment

Uh oh!

anntzer Apr 24, 2022

Choose a reason for hiding this comment

Uh oh!

jklymak commented Jan 26, 2023

Uh oh!

Uh oh!

oscargus commented Mar 20, 2022 •

edited

Loading