-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Plots with many subplots can be slow #867
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
The lack of improvement that I reported with #549 has always bothered me; it was an impression, not a measurement. So, I went back to it, and tried timing plt.draw() with the array of subplots. I find there is an improvement on my machine, from 0.53 s per draw to 0.37 s per draw; it just wasn't dramatic enough to be visually obvious when I was testing by manual zooming and panning. Maybe it is still worthwhile, if on a substantial sample of machines the improvement is more tangible. The extra complexity does make me hesitate, though. |
I tend to agree -- anytime caching is introduced to speed something up, things can get much more brittle to change and full of unintended side effects. #549 does somewhat illustrate where a good 40% of the time is going though -- there just might be a better way to speed it up than just caching. |
Closing this as no work has been done on it in 2 years and the assumption that Moore's Law is on our side. |
Is there any update on this? I currently need to have a figure containing 16 x 33 subplots and it takes ages to load. |
It sounds like the relevant issue is #6664, in particular #6664 (comment). |
Originally reported by John Gu on the mailing list thread "extreme navigation slowness for subplots".
#549 was a proposed solution to the problem that did not seem to create improvement for all users.
Script to reproduce the issue:
The text was updated successfully, but these errors were encountered: