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