-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
[Bug]: slow rendering of multiple axes (time scales as 2nd power of label count) #21895
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I can confirm the issue. This occurs because text layouting is somewhat slow, but most of the code assumes it's cheap because we have caches at matplotlib/lib/matplotlib/text.py Line 110 in c9582f0
matplotlib/lib/matplotlib/mathtext.py Line 437 in c9582f0
but unfortunately you have more ticklabels than the cache and the strings get repeatedly reparsed. Indeed, increasing the size of either cache to 10000 fixes the slowness (the mathtext cache only affects the use_math case, of course). I guess(?) a fix is to move the Text._cached cache info to a private attribute on each Text instance, so that each instance caches its own info and at least we don't get limited artificially by the arbitrary cache size. |
I am 👍🏻 on moving the state caching into the I'm labeling this as a good first issue as it does not involve any API design choices, but it will need an intermediate understanding of Python as you will need to chase through the code to where the cached functions are called from and hoist the cache management up a level (or three). Timing tests are notoriously hard to get right on CI (because we are running on free CPU on the cloud there is a lot of variability and we get preempted in favor of paying customers (which is quite fair!)) and between machines. Maybe compare the render times of a figure with lots of math text and one with no text? If we want to verify that the caching helps, maybe verify that the first draw is slower than the second? That is a long way of saying, a PR with a performance regression test is better, but I would not block merging over it. |
Can I work on this issue @tacaswell @anntzer? :) |
Go ahead, I agree with @tacaswell's assessment on the issue. There's a somewhat similar cache on images (_imcache and _rgbacache) which may or may not be worth comparing with to understand the caching here. |
AFAICT this has been fixed by #22271, please confirm? |
Closing as tentatively fixed by #22271. |
Bug summary
I need to label a lot of elemental emission peaks on X-ray spectra. There are three series of peaks denoted K, L and M, so I put three axes above the plot. (This is the best approach I could find online, it does not seem that multiple text labels would be covered in the docs. I will be thankful for any tip.)
Anyway, the plotting then goes very very slow: roughly 4× slower when the number of labels doubles.
Code for reproduction
Actual outcome
By default
QtAgg
is used. Withuse_math=True
it takes 1m59,698s, without it only 0m18,759s.When I switch backend to
cairo
: Withuse_math=True
it takes 1m30,385s, without it only 0m11,522s. Still a lot.Expected outcome
Such a simple plot could render within few seconds, even if lower indices are used rendered using the $ ... $ notation.
Also, as a separate minor bug, I can see
fontsize=8
has applied on the first extra axis only. The other two would not change their font size even when explicitly asked for.Additional information
This bug was observed also in Matplotlib 3.1.x taken from the Ubuntu repository. Today I checked out the devel version and it is basically the same.
Almost all the code runs within a second. The slow command is the
savefig
.I don't know why this happens, it looks like if every next label somehow needed to "update" all existing ones; this would explain the quadratic dependence of time.
I don't know any fix.
Operating system
Ubuntu
Matplotlib Version
3.6.0.dev995+g21b76ae7f7
Matplotlib Backend
QtAgg by default,
Python version
Python 3.8.10 (default, Sep 28 2021, 16:10:42)
Jupyter version
N/A
Installation
git checkout
The text was updated successfully, but these errors were encountered: