John, Tom, I don't understand how generation of the identity transform for each Artist instance could possibly be a significant overall slowdown; it should be very fast, and only a small part of the time required to actually do anything useful with an Artist instance. I am wondering whether this could be a problem with the profiler, not a genuine slowdown.
Eric John Hunter wrote: >>>>>> "Tom" == Tom Denniston <[EMAIL PROTECTED]> writes: > > Tom> I've been profiling some of my code which builds many > Tom> somewhat complex graphs. I've noticed that it spends almost > Tom> all it's time in the __init__ of the artist class. The time > Tom> there is almost entirely spent on calling identity_transform > Tom> which builds a SeperableTransform that does no > Tom> transforming--from what I can tell--which is consistent with > Tom> the name. The identity transform function buid a bunch of > Tom> other objects all of which are the same each time. My > Tom> question is, does it really need to build all these objects > Tom> over and over again. Given that Artist's __init__ is called > Tom> by so many things wouldn't it be better to have some static > Tom> constants to define these default transformation functions? > Tom> Am I missing something subtle or would this be an > Tom> improvement? > > I'm hesitant to make a single (shared) identity transform since > transforms are mutable. But since most objects to not use the > identity_transform but rather a custom one, we can create it > lazily. I've implemented these changes in svn. Each artist (as > before) has a _transform instance but now it defaults to None. Then > in get_transform > > def get_transform(self): > 'return the Transformation instance used by this artist' > if self._transform is None: > self._transform = identity_transform() > return self._transform > > The harder part was modifying all of the derived classes that were > using the _transform attr directly -- all these had to be ported to > use get_transform instead. The changes are documented in API_CHANGES. > > See if it speeds up your code -- it didn't make an appreciable change > to backend_driver. > > Note the artist constructor shouldn't be a bottleneck in your python > script. If it is, you are probably creating lots-o-artists and you > might be able to use a collection instead. Eg, if you are making > hundreds or thousands of calls to plot and creating a comparable > number of Line2D artists, use a LineCollection instead. > > But if you are still experiencing a problem and the changes I made to > svn don't help (eg if you are creating lots of objects that do require > the default identity_transform), you can experiment with using a > single cached identity_transform. Something like > > import matplotlib.artist > > _cached_transform = matplotlib.artist.identity_transform() > def my_identity_transform(): > return _cached_transform > matplotlib.artist.identity_transform = my_identity_transform > > # import the rest of mpl here > > > > Hope this helps... > > JDH > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Matplotlib-users mailing list > Matplotlib-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-users ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
