Repository navigation
[Bug]: matplotlib.pyplot.clf is very slow #23771
Description
Bug summary
For relatively simple plotting examples the plt.clf() command can take over 30% of the calculation time. One would expect that a clear command is relatively simple and takes a limited amount of time
Code for reproduction
import numpy as np
import time
import matplotlib
import matplotlib.pyplot as plt
print(matplotlib.__version__)
def profile_expression(expression):
import cProfile
import tempfile
import os
import subprocess
tmpdir = tempfile.mkdtemp()
statsfile = os.path.join(tmpdir, "profile_expression_stats")
print("profile_expression: running")
t0 = time.perf_counter()
cProfile.run(expression, statsfile)
dt = time.perf_counter() - t0
print(f"profiling: {dt:.2f} [s]")
r = subprocess.Popen(["snakeviz", statsfile])
return r
x=np.linspace(0, 10, 1000)
y=np.linspace(0, 20, 1000)**0.1
def go():
for ii in range(5):
plt.figure(100);
plt.clf()
plt.plot(x, y, '.', label='n')
plt.plot(x, y+x, '.-', label='m')
plt.xlabel('dsf')
plt.title('sdfs')
plt.legend()
plt.draw()
if __name__=='__main__':
profile_expression('go()')Actual outcome
The output of the minimal example (which requires https://github.com/jiffyclub/snakeviz to be installed) is a profiling graph of the code executed in the minimal example:
Expected outcome
The plt.clf() should be very fast compared to the actual plotting. Going into the details of the profiling results shows a large amount of time being spend in axis.reset_ticks.
Additional information
No response
Operating system
Windows
Matplotlib Version
3.6.0.dev3058+g87197156eb
Matplotlib Backend
Qt5Agg
Python version
3.10.0
Jupyter version
No response
Installation
git checkout
Activity
timhoffm commented on Aug 29, 2022
Tick handling is a known performance issue, but it's hard to change due to compatibility (see #5665 for a general discussion).
We already have some optimizations, but they may not apply to reset_ticks(). How is the timing when you discard the figure and create a new one instead? It might be that this is faster:
for ii in range(5): plt.figure(ii); plt.plot(x, y, '.', label='n') plt.plot(x, y+x, '.-', label='m') plt.xlabel('dsf') plt.title('sdfs') plt.legend() plt.draw() plt.close()Edit: The clearing issue is also described/addressed in #16067
tacaswell commented on Aug 29, 2022
I'm also a bit surprised how much time we are spending in the deprecation machinery....
eendebakpt commented on Aug 30, 2022
The overhead of the deprecation is really low. The reported times in the profiling graph are cummulative which is why they show up. What you see is just this:
@functools.wraps(func) def wrapper(*args, **kwargs): # Don't use signature.bind here, as it would fail when stacked with # rename_parameter and an "old" argument name is passed in # (signature.bind would fail, but the actual call would succeed). if len(args) > name_idx: warn_deprecated( since, message="Passing the %(name)s %(obj_type)s " "positionally is deprecated since Matplotlib %(since)s; the " "parameter will become keyword-only %(removal)s.", name=name, obj_type=f"parameter of {func.__name__}()") return func(*args, **kwargs)eendebakpt commented on Aug 30, 2022
Creating new figures (e.g. plt.figure(ii) instead of plt.figure(100); plt.clf()) is slower.
eendebakpt commented on Jul 3, 2023
The method reset_ticks seems to be called a lot, also on ticks (xticks, yticks) that have already been reset. Adding this snippet
import os from inspect import stack def fmt(f): bname = os.path.basename(f.filename) s=f'{bname}: line {f.lineno}: function {f.function}' s+=' '*max(0, 40-len(s)) return f'{s} <-- context {f.code_context}' print("reset_ticks:") s=stack() for ii,f in enumerate(s[0: min(15, len(s))]): print(f' {ii}.{fmt(f)}')to reset_ticks in matplotlib/axis.py gives some information on where the reset_ticks is triggered.
Example output for script
plt.figure(100); print('# gca') ax=plt.gca() print('# clf') plt.clf()is
timhoffm commented on Sep 9, 2024
To be checked: Why do we clear the Axes before deleting them?
matplotlib/lib/matplotlib/figure.py
Line 987 in 5461ae2
Axes.clear() is expensive because of the tick logic. But resetting ticks is not necessary when we remove the Axes anyway. We should try and remove that ax.clear() call. It might be that this call was introduces to cleans up some additional stuff, but OTOH if that's the case it should be handled in delaxes() (delaxes is a public API and should work with any Axes, not just cleared ones).
tacaswell commented on Sep 9, 2024
My off-the-cuff guess is that we are doing that to help the garbage collector out and break some of the reference cycles.
timhoffm commented on Sep 9, 2024
Ok, then we could possibly write some more lightweight prepare_del() (better name t.b.d.) function that untangles an Axes from all relations without resetting internal state unnecessarily.