Repository navigation
IPython is always imported by pyplot, if present #5037
Description
When IPython is present, the import time for pyplot is roughly doubled because IPython is imported by install_repl_displayhook(). This is true even with matplotlib.use('agg'), so it will affect all scripts using pyplot.
Activity
PRF: only try IPython if it is already imported
OceanWolf commentedon Sep 9, 2015
Hmm, going back to what I said in the line comments of #4506, lets control this auto-redraw based on a simple rcParam check rather than using iPython...
tacaswell commentedon Sep 9, 2015
There are two ways to deal with clearing the stale state. Either when the figure comes stale it can tell the canvas to schedule a re-draw at it's next opportunity (which is what happens currently if you are not in
IPython) and the other is that some external loop comes around and asks the figures if they are stale, and if so, triggers the canvas to re-draw.I very much prefer option 2 as it puts control of the draw cadence in the hands of the event loop that is running the show, instead of mpl constantly poking at the canvas. It prevents any possibility of the nasty infinite draw-triggering-draw loops that we had to deal with (but I think those are all sorted out for the backends we ship).
The plain python repl does not have a convenient place to hook a callback function into, hence in that case we have to use the push pattern.
I don't see how in either case an rcparam helps deal with when to trigger asynchronous draws.
efiring commentedon Sep 9, 2015
It's greatly improved, but I'm still seeing a considerable increase in import time from 1.4.3 to master, with #5038 included. The number of function calls has gone from 179,087 to 252,421, and the time is still about 100 ms longer (280 to 380) on my Linux VM. The increase is split between the
matplotlib.__init__and thepyplot, with a somewhat larger fractional contribution from the latter. (This is based on stats from a single run with kernprof.) Has our LOC count increased by this much? About 40%? I wouldn't think so.tacaswell commentedon Sep 9, 2015
according to git we are net +22k LoC, but a lot of that is probably svgs
mdehoon commentedon Sep 9, 2015
Option 1 is the traditional way of organizing event loops on Windows, Mac, X11. I would suggest to consider carefully why matplotlib would need an approach different from other GUI programs.
I believe you were looking for a function that is called when Python is waiting for the next command?
If so, then at least with tkagg you could use Tkinter's after_idle.
OceanWolf commentedon Sep 9, 2015
Yes, I thought we had
draw_idleto do exactly that. It works like a mailbox flag. When you change some properties that means we need the artist redrawn, we raise the flag to say "come here", and notify the system that it needs to make a round when it has free time. Based on previous comments regarding embedding, I think we would want to use an rcParam to control whether the artist will raising of the flag will automatically request a draw_idle. As with the mail, If the draw_idle execution has not yet begun, another request for it will just represent a no-op.Anyway, not a biggie, I think we can change to this or some other behaviour safely enough at a later point... but I thought if we needed to get rid of that IPython import now, then we can/should do it this way.