WCSAxes: pre-compute the coord range to eliminate redundant transformations when drawing ticks/gridlines

[ayshih]

Description

From #16362:

When WCSAxes draws ticks/gridlines, it performs a pixel->world transform of (by default) a 50x50 grid of pixels, but it currently performs the identical calculation a total of four times: once when drawing ticks, again when drawing gridlines, and doubled because there are two components. These redundant calculations are particularly expensive when working with grid overlays (world->world) because then the coordinates framework is being used.

Inspired by @astrofrog, this PR pre-computes the coord range at just the right spot to exactly cover these four transformations, so now only one transformation is performed.

Fixes #16362

• By checking this box, the PR author has requested that maintainers do NOT use the "Squash and Merge" button. Maintainers should respect this when possible; however, the final decision is at the discretion of the maintainer that merges the PR.

[github-actions]

Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

• Do the proposed changes actually accomplish desired goals?
• Do the proposed changes follow the Astropy coding guidelines?
• Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
• Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
• Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see instructions for rebase and squash.
• Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
• Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
• Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
• At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

[github-actions]

👋 Thank you for your draft pull request! Do you know that you can use [ci skip] or [skip ci] in your commit messages to skip running continuous integration tests until you are ready?

[astrofrog]

Nice! How much is the overall performance improvement with this for solar data?

[pllim]

Is this performance covered by https://github.com/astropy/astropy-benchmarks/blob/main/benchmarks/visualization/wcsaxes.py ? If so, can slap a benchmark label and let it run.

[astrofrog]

We might as well try that as we should at least see a small improvement even for non solar coordinates!

[pllim]

FWIW the benchmark here doesn't indicate anything has changed in wcsaxes stuff but it can also be flaky. 🤷‍♀️

https://github.com/astropy/astropy/actions/runs/8911393283/job/24474385670?pr=16366

[astrofrog]

The improvements here are likely only for cases with slow coordinate transformations, which probably explains it.

[ayshih]

Okay, I had thought there'd be a gigantic performance gain for large images because I thought find_coordinate_range() was performed a pixel->world->world transformation of all pixels, but the sampling is actually constrained by conf.coordinate_range_samples, which defaults to 50. That is, by default, this PR eliminates three redundant transforms of a 50x50 pixel grid, which at 2500 points is comparable to a couple of gridlines.

If we start with the same benchmark test but specify the overlay to be in TETE rather than FK5 to inflate the computation times, here is the comparison of some performance numbers:

• Each run of find_coordinate_range() for the base grid: 3 ms
• Each run of find_coordinate_range() for the overlay: 13 ms
• Before this PR:
  • Without the overlay: 80 ms
  • With the overlay: 480 ms
• After this PR:
  • Without the overlay: 70 ms
  • With the overlay: 540 ms

So, it looks like a ~10% increase in performance when there are only a few gridlines. This fractional benefit will be much smaller if there are lots of gridlines.

[ayshih]

Amusingly, it's possible to make the performance gains from this PR arbitrarily large by increasing conf.coordinate_range_samples by orders of magnitude. At conf.coordinate_range_samples = 1000, find_coordinate_range() can take ~1 second to run and dominates the total plotting run time, so this PR reduces the run time by 75%.