-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
legend is eating up huge amounts of memory #19345
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
You are removing the lines each call but not the legend so you end up w thousands of legends. I'm going to close but feel free to ask for more help at discourse.matplotlib.org |
I already tried with removing the legend every time the plot gets updated, but that did not help in any way. Also, I'd consider it a bug if a plot could have more than one legend. Should I submit a new bug report, or will you re-open this issue? |
Again I think discourse would be the more appropriate place to discuss until we know what the problem is. Certainly Matplotlib was not designed around for legend to be called thousands of times. If you are just trying to animate a line you should probably not be removing it, but rather setting the x and y data, in which case the legend is called upon setup rather than at each draw |
Ok, I posted this at https://discourse.matplotlib.org/t/legend-is-eating-up-a-lot-of-memory |
I can reproduce the leak (which is quite slow, you need to run the code for minutes at least to see it). https://pypi.org/project/memory-profiler/ is a good way to measure such things. One thing to try would be first to check whether this is wx-specific, or whether this also happens with other GUI toolkits. |
As discussed on https://discourse.matplotlib.org/t/legend-is-eating-up-a-lot-of-memory it would be nice to strip this from the app and see if the problem persists. |
Here is a very small example without
|
Thanks a lot for the minimal example. I agree that legend seems to be leaking. Even |
I believe I figured out at least some of the problem: we're not clearing out unit-handling callbacks properly when gc'ing Line2Ds. At least the following should help; can you confirm? diff --git i/lib/matplotlib/cbook/__init__.py w/lib/matplotlib/cbook/__init__.py
index 31055dcd7..755a4c8ea 100644
--- i/lib/matplotlib/cbook/__init__.py
+++ w/lib/matplotlib/cbook/__init__.py
@@ -217,7 +217,8 @@ class CallbackRegistry:
return
for signal, proxies in list(self._func_cid_map.items()):
try:
- del self.callbacks[signal][proxies[proxy]]
+ cid = proxies.pop(proxy)
+ del self.callbacks[signal][cid]
except KeyError:
pass
if len(self.callbacks[signal]) == 0:
@@ -241,6 +242,7 @@ class CallbackRegistry:
if value == cid:
del functions[function]
return
+ self._pickled_cids.discard(cid)
def process(self, s, *args, **kwargs):
""" |
I do not know how to apply this code modification, so I cannot test this. I guess others who are more into the code should be able to help. |
Should be fixed by #19480. |
Bug report
Bug summary
I have a Python program that gets data from a measurement instrument and plots the data using matplotlib. A separate thread is used to trigger updating of the plots at fixed time intervals.
After a while, the program will take up huge amounts of memory (gigabytes after a few hours). The simplified code below is a self-contained example that illustrates the effect. The issue does not happen if the code is modified to skip the axes.legend(...) call on line 92, i.e., if no legend is drawn.
If I put some pressure on the system by running another application that will consume a lot of memory, my Python program will at some point start to release the excessive memory used up by matplotlib (ending up at about 60 MB or so). Releasing the memory does not seem to have any negative effects on the operation of my program. This tells me that the large junk of memory used by matplotlib is not vital (if not useless) in my application.
I believe the unnecessary memory usage related to the legend is a bug, or at least something very obscure that seems wrong to me. How can this issue be avoided or fixed?
Code for reproduction
Matplotlib version
Matplotlib and all other software used here was installed from Debians repositories, using the Debian package management system.
The attached screenshot shows the memory situation after running the code with and without the legend for a few minutes. The version without the legend will stay at the memory usage shown, whereas the memory usage of version with the legend will increase until it approaches the limits of the system.

The text was updated successfully, but these errors were encountered: