Skip to content
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

Stem is slow and will crash if I try to close the window #7969

Closed
goldfita opened this issue Jan 28, 2017 · 14 comments
Closed

Stem is slow and will crash if I try to close the window #7969

goldfita opened this issue Jan 28, 2017 · 14 comments
Assignees
Milestone

Comments

@goldfita
Copy link

Bug summary

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.

@tacaswell
Copy link
Member

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.

@tacaswell tacaswell added this to the 2.1 (next point release) milestone Jan 28, 2017
@tacaswell tacaswell added the status: needs clarification Issues that need more information to resolve. label Jan 28, 2017
@goldfita
Copy link
Author

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
Copy link
Member

It is not finger pointing, just sorting out what the actual bug is.

attn @jheinen

@jheinen
Copy link
Contributor

jheinen commented Jan 28, 2017

This is how you can reproduce the bug (in Python)

import matplotlib.pyplot as plt
import numpy as np
plt.stem(np.random.randn(10000))

Fails on macOS X, can't check other backends before Monday ...

@anntzer
Copy link
Contributor

anntzer commented Jan 28, 2017

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.

@anntzer
Copy link
Contributor

anntzer commented Feb 16, 2017

(but LineCollection currently cannot take a custom marker :-()

@tacaswell tacaswell removed the status: needs clarification Issues that need more information to resolve. label Feb 17, 2017
@tacaswell
Copy link
Member

At a minimum, we could save some time by not going through plot

@tacaswell tacaswell modified the milestones: 2.2 (next next feature release), 2.1 (next point release) Aug 14, 2017
@dstansby
Copy link
Member

Having a look at this and think I'm making progress

@dstansby dstansby self-assigned this Oct 24, 2017
@terriyu
Copy link

terriyu commented 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
Copy link

grr37213 commented 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
Copy link

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
Copy link
Member

I'm afraid this is only going to be in 3.1.x onwards.

@timhoffm
Copy link
Member

But 3.1.0 should hopefully come out soon 😄 .

@tacaswell
Copy link
Member

Hopefully today or tomorrow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants