On Tue, Oct 7, 2008 at 9:18 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> According to lsprofcalltree, the slowness appears to be entirely in the
> units code by a wide margin -- which is unfortunately code I understand very
> little about.  The difference in timing before and after adding the line to
> the axes appears to be because the unit conversion is not invalidated until
> the line has been added to an axes.
>
> In units.get_converter(), it iterates through every *value* in the data to
> see if any of them require unit conversion, and returns the first one it
> finds.  It seems like if we're passing in a numpy array of numbers (i.e. not
> array of objects), then we're pretty much guaranteed from the get-go not to
> find a single value that requires unit conversion so we might as well not
> look.  Am I making the wrong assumption?
>
> However, for lists, it also seems that, since the code returns the first
> converter it finds, maybe it could just look at the first element of the
> sequence, rather than the entire sequence.  It the first is not in the same
> unit as everything else, then the result will be broken anyway.

I made this change -- return the converter from the first element --
and added Michael's non-object numpy arrat optimization too.  The
units code needs some attention, I just haven't been able to get to
it...

This helps performance considerably -- on backend driver:

Before:
  Backend agg took 1.32 minutes to complete
  Backend ps took 1.37 minutes to complete
  Backend pdf took 1.78 minutes to complete
  Backend template took 0.83 minutes to complete
  Backend svg took 1.53 minutes to complete

After:
  Backend agg took 1.08 minutes to complete
  Backend ps took 1.15 minutes to complete
  Backend pdf took 1.57 minutes to complete
  Backend template took 0.61 minutes to complete
  Backend svg took 1.31 minutes to complete

Obviously, the results for tests focused on lines with lots of data
would be more dramatic.


Thanks for these suggestions.
JDH

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Reply via email to