how to make matplotlib faster?

In thinking about the ioff(), ion() approach it occurs to

    > me that it may not be quite so simple for scripts. I think
    > a common desire is for a script or function to turn off
    > interactive mode if it is on, but at the end, restore the
    > previous interactive state. In this case a push/pop
    > approach to interactive mode may be more appropriate rather
    > than stop/start. In particular, if interactive mode
    > happended to be off, you wouldn't want to turn it on at the
    > end of the script.

BTW, Eric emailed me off list. It appears that running his script in
interactive mode was the root cause of his performance problems.

In regards to running scripts from the python shell, I think the least
invasive approach is to write a run function that stores the
interactive state, calls ioff, runs the script with execfile, then
calls ion (precisely what ipython does). In fact, perhaps we should
add a run function to the pylab interface which does just this.
Fernando could simply override this function if he wants to do some
additional ipython magic. But this would wrap the logic for those who
want to run scripts from the other python shell. Of course it would
only work for non-image backends and Tk, or GUI backends associated
with a GUI shell like pycrust.

I'm less worried about people inadvertently running scripts from the
command shell with interactive set to True, because interactive
defaults to False in rc and thus the person would have had to
intentionally change it, at least at some point in dark history.
Hence they are probably aware of it. Singing the praises of ipython
yet again, I leave the default in my rc to False, and run ipython when
I want to work interactively, letting ipython turn interaction on for
me. Thus I can run python somescript.py from the command shell assured
that it is off, and still use matplotlib interactively w/o having to
tweak the setting.

But if there is some concern for users who would like to leave
interactive on in rc (eg they like to use the standard python shell or
some other shell) and still be able to get the efficiency when running
scripts from the command shell, it might be possible to inspect
whether we are in a running in a python shell, and plug this
additional information into draw_if_interactive. Something like

def draw_if_interactive():
    if running_in_python_shell() and matplotlib.is_interactive():
       canvas.draw()

Anyone know how to determine whether you are running code in a python
shell versus running a script, eg from a command shell?

It occurs to me that "interactive" is not really the best name for
this matplotlib state. Really we want something that conveys
"draw_after_every_plot_command". When I named it, I was assuming that
when working interactively you would want to update with every plot
command, but have learned that this is not always the case. Do you
think it's worth coming up with new names (isdraw(),
draw_always(True/False), etc, while preserving the old names for a
while with deprecation)? Because that's what we're really doing,
controlling the drawing.

JDH

John,
I think the push/pop functions are going to be fairly useful (ipush and ipop??). We're going to be writing a lot scripts (i.e. functions) that generate plots for our users. There is no way to tell inside the script if it's going to be used by a user in interactive mode or by another script (like a batch report generator). Having push/pop would let me do:

def stdPlot( [inputs] ):
    ipush( False )
    try:
       [ create plot ]
    finally:
       ipop()

Of course it's pretty easy to roll your own but I think it would be nice to have it in the standard set of commands.

···

At 05:54 AM 12/12/2004, John Hunter wrote:

    > In thinking about the ioff(), ion() approach it occurs to
    > me that it may not be quite so simple for scripts. I think
    > a common desire is for a script or function to turn off
    > interactive mode if it is on, but at the end, restore the
    > previous interactive state. In this case a push/pop
    > approach to interactive mode may be more appropriate rather
    > than stop/start. In particular, if interactive mode
    > happended to be off, you wouldn't want to turn it on at the
    > end of the script.

BTW, Eric emailed me off list. It appears that running his script in
interactive mode was the root cause of his performance problems.

In regards to running scripts from the python shell, I think the least
invasive approach is to write a run function that stores the
interactive state, calls ioff, runs the script with execfile, then
calls ion (precisely what ipython does). In fact, perhaps we should
add a run function to the pylab interface which does just this.
Fernando could simply override this function if he wants to do some
additional ipython magic. But this would wrap the logic for those who
want to run scripts from the other python shell. Of course it would
only work for non-image backends and Tk, or GUI backends associated
with a GUI shell like pycrust.

I'm less worried about people inadvertently running scripts from the
command shell with interactive set to True, because interactive
defaults to False in rc and thus the person would have had to
intentionally change it, at least at some point in dark history.
Hence they are probably aware of it. Singing the praises of ipython
yet again, I leave the default in my rc to False, and run ipython when
I want to work interactively, letting ipython turn interaction on for
me. Thus I can run python somescript.py from the command shell assured
that it is off, and still use matplotlib interactively w/o having to
tweak the setting.

But if there is some concern for users who would like to leave
interactive on in rc (eg they like to use the standard python shell or
some other shell) and still be able to get the efficiency when running
scripts from the command shell, it might be possible to inspect
whether we are in a running in a python shell, and plug this
additional information into draw_if_interactive. Something like

def draw_if_interactive():
    if running_in_python_shell() and matplotlib.is_interactive():
       canvas.draw()

Anyone know how to determine whether you are running code in a python
shell versus running a script, eg from a command shell?

It occurs to me that "interactive" is not really the best name for
this matplotlib state. Really we want something that conveys
"draw_after_every_plot_command". When I named it, I was assuming that
when working interactively you would want to update with every plot
command, but have learned that this is not always the case. Do you
think it's worth coming up with new names (isdraw(),
draw_always(True/False), etc, while preserving the old names for a
while with deprecation)? Because that's what we're really doing,
controlling the drawing.

JDH

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Ted Drain Jet Propulsion Laboratory ted.drain@...369...

Yes, this was exactly the kind of usage I was envisioning. In other words,
I don't care what mode the user is using, I want this to run in "noninteractive"
mode (according to its current meaning), but I don't want to screw up their
state.

Perry

···

On Dec 13, 2004, at 2:57 PM, Ted Drain wrote:

John,
I think the push/pop functions are going to be fairly useful (ipush and ipop??). We're going to be writing a lot scripts (i.e. functions) that generate plots for our users. There is no way to tell inside the script if it's going to be used by a user in interactive mode or by another script (like a batch report generator). Having push/pop would let me do:

def stdPlot( [inputs] ):
   ipush( False )
   try:
      [ create plot ]
   finally:
      ipop()

Of course it's pretty easy to roll your own but I think it would be nice to have it in the standard set of commands.