Thanks for the diagnosis! I think the main thing to figure out is how to determine if the transform has changed compared to a previous call, i.e. how to determine the key for the hash. We might also want to see if it would be easier to do the caching at the Transform-class level since it's easier for transforms to be aware of whether any of their internal parameters have changed.

One of the main difficulties with caching is going to be knowing if the WCS has changed in any way. For FITS WCS, hash(wcs) does not change even if some of the transformation parameters change.

If we can't figure this out, then the next best option will be to have some way in WCSAxes of temporarily setting some kind of context within which the four transformation will happen and assuming that within that context the WCS won't get modified (which is reasonable). We might need to do this because we will probably need to assume within this that the coordinate transformation graph doesn't get modified.

If we can't figure this out, then the next best option will be to have some way in WCSAxes of temporarily setting some kind of context within which the four transformation will happen

Ooh, that's a simple solution. The four transformations are actually all tightly grouped in the following loop (._draw_grid() calls both ._update_ticks() and ._update_grid_lines()), so a context isn't even really necessary:

#16366 solves the immediate issue by reducing the four transformations to just one. It doesn't do anything for redundant transformations if WCSAxes.draw_grid() is called multiple times with an unchanged WCS, but that's beyond the scope of what I meant by this issue.