You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Stem is slow and will crash if I try to close the window #7969
Stem will crash if you try to close the window while it's processing. It's also very slow for what I would consider a relatively small number of data points. I'm using the code from Julia, but I was informed the problem is Matplotlib. See original discusion.
Code for reproduction
using PyPlot
stem(randn(32768))
Actual outcome
This will work if you wait about half a minute. If you interfere by trying to close the window, the application crashes (Julia in this case).
Matplotlib version
I don't know. I'm using the most recent version of PyPlot and PyCall in Julia 0.5. Conda installed Python 2.7.
I tried just now. I'm afraid I'm too much of a beginner with both Julia and Matplotlib to figure this out. However, poster jheinen on the Julia forum claims to have reproduced this problem in pure Python. I suggest asking him for his code. I'm sorry I can't be of any more help. I don't want to get in the middle of any finger pointing between these two communities.
Indeed, this is likely due to the fact that stem generates one Line2D per stem, rather than grouping everything in a LineCollection, which would probably improve the performance quite a bit.
I also confirmed this bug in Python 3 on Ubuntu 16.04. I tried to plot a stem plot with 130,000 points and the computer crunched on it a long time without displaying anything.
Since I encountered this problem by plotting around 30000 data points today I found this issue.
I can only link to this workaround I found, which solved my problem through manually calculating the line, coordinates and plotting a line collection, instead of using stem itself. https://stackoverflow.com/questions/48301044/optimization-of-matplotlib-stem-plot
Maybe it helps someone.
Activity
tacaswell commentedon Jan 28, 2017
Can you please provide python code that generate the issue? As the julia folks point at us, it is not clear that this is not a bug on the julia side.
goldfita commentedon Jan 28, 2017
I tried just now. I'm afraid I'm too much of a beginner with both Julia and Matplotlib to figure this out. However, poster jheinen on the Julia forum claims to have reproduced this problem in pure Python. I suggest asking him for his code. I'm sorry I can't be of any more help. I don't want to get in the middle of any finger pointing between these two communities.
tacaswell commentedon Jan 28, 2017
It is not finger pointing, just sorting out what the actual bug is.
attn @jheinen
jheinen commentedon Jan 28, 2017
This is how you can reproduce the bug (in Python)
Fails on macOS X, can't check other backends before Monday ...
anntzer commentedon Jan 28, 2017
Indeed, this is likely due to the fact that
stemgenerates one Line2D per stem, rather than grouping everything in a LineCollection, which would probably improve the performance quite a bit.anntzer commentedon Feb 16, 2017
(but LineCollection currently cannot take a custom marker :-()
tacaswell commentedon Feb 17, 2017
At a minimum, we could save some time by not going through
plotdstansby commentedon Oct 24, 2017
Having a look at this and think I'm making progress
terriyu commentedon Feb 1, 2018
I also confirmed this bug in Python 3 on Ubuntu 16.04. I tried to plot a stem plot with 130,000 points and the computer crunched on it a long time without displaying anything.
grr37213 commentedon Aug 16, 2018
Since I encountered this problem by plotting around 30000 data points today I found this issue.
I can only link to this workaround I found, which solved my problem through manually calculating the line, coordinates and plotting a line collection, instead of using stem itself.
https://stackoverflow.com/questions/48301044/optimization-of-matplotlib-stem-plot
Maybe it helps someone.
racinmat commentedon May 15, 2019
Will this be merged to some 3.0.x version, or do we need to wait for stable 3.1.x version if we want this fixed in pip?
dstansby commentedon May 15, 2019
I'm afraid this is only going to be in
3.1.xonwards.timhoffm commentedon May 15, 2019
But 3.1.0 should hopefully come out soon 😄 .
tacaswell commentedon May 15, 2019
Hopefully today or tomorrow.