Re: [matplotlib-devel] imshow: set_extent
On Wednesday 15 August 2007 05:05:51 pm you wrote: > Darren Dale wrote: > > I'm doing something along the lines of: > > > > create an initial image with imshow > > add a colorbar > > update the image using the image's set_data method > > > > Occassionally, the extents of the image will change. How do I handle > > that? The only place I can find to set the extents is in the call to > > imshow. The resulting image has a get_extents, but not a setter. I can't > > make repeated calls to imshow, because the new image isnt coupled to the > > colorbar. I can't figure out how to couple the colorbar to the new image, > > and I dont know how to get rid of the old colorbar to clear space for a > > new one. > > Darren, > > Try directly setting the extent via the _extent attribute of the image > object. If that works and doesn't cause any new problems, then we can > add a trivial set_extent method. I just committed this patch in svn. The additional code was lifted from imshow, to reshape the axes along with the image. Darren Index: lib/matplotlib/image.py === --- lib/matplotlib/image.py (revision 3709) +++ lib/matplotlib/image.py (working copy) @@ -236,6 +236,18 @@ # by mistake. self.set_data(A) + +def set_extent(self, extent): +"""extent is data axes (left, right, bottom, top) for making image plots +""" +self._extent = extent + +xmin, xmax, ymin, ymax = extent +corners = (xmin, ymin), (xmax, ymax) +self.axes.update_datalim(corners) +if self.axes._autoscaleon: +self.axes.set_xlim((xmin, xmax)) +self.axes.set_ylim((ymin, ymax)) def get_interpolation(self): """ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experimental, traited config module available in svn
Hi guys, [ For the Enthought gang, sorry for the cross-post. This is the context: http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/msg01451.html We're trying to see if it would be reasonable to use Traits for the matplotlib config description, but there seem to be performance issues. ] On 7/31/07, Eric Firing <[EMAIL PROTECTED]> wrote: > Darren, > > The two cases you ran have almost identical timing, so the problem is > not in reading matplotlib.conf. Instead, it seems to be in the > initialization of all the machinery, and I suspect that something may > be getting run many times in a loop instead of just once. I used the > profile.py script method to profile the whole simple_plot.py demo > modified to use Agg, with NEWCONFIG True versus False. Attached are the > top 100 lines of the output, sorted by cumulative time, with "new" > meaning NEWCONFIG=True. The execution time of the new version is 3.2 > seconds versus 1.8 for the old. (Both are pretty slow for making a > minimal plot from a script.) > I'm here at scipy'07 with the Enthought folks and trying to see if we can understand what the issue with this traits startup cost is. But I tried (with current SVN) to run a simple python -c 'import pylab;pylab.plot([1,2,3])' but I'm gettting: obj: plain Traceback (most recent call last): File "", line 1, in File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/pylab.py", line 2061, in plot b = ishold() File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/pylab.py", line 888, in ishold return gca().ishold() File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/pylab.py", line 834, in gca ax = gcf().gca(**kwargs) File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/figure.py", line 722, in gca return self.add_subplot(111, **kwargs) File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/figure.py", line 542, in add_subplot a = Subplot(self, *args, **kwargs) File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axes.py", line 5157, in __init__ self.figW, self.figH], **kwargs) File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axes.py", line 507, in __init__ self._init_axis() File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axes.py", line 545, in _init_axis self.xaxis = maxis.XAxis(self) File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axis.py", line 512, in __init__ self.label = self._get_label() File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axis.py", line 990, in _get_label horizontalalignment='center', File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/text.py", line 178, in __init__ self.set_markup(markup) File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/text.py", line 780, in set_markup self._markup = rcParams['text.markup'] File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/config/mplconfig.py", line 438, in __getitem__ return getattr(obj, attr) AttributeError: 'str' object has no attribute 'markup' where the crash is coming from this (run interactively in ipdb): /home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/config/mplconfig.py in __getitem__(self, key) 436 obj, attr = self.tconfig_map[key] 437 print 'obj:',obj --> 438 return getattr(obj, attr) 439 440 def keys(self): AttributeError: 'str' object has no attribute 'markup' In [2]: obj: MPLConfig In [3]: debug > /home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/config/mplconfig.py(438)__getitem__() 437 print 'obj:',obj --> 438 return getattr(obj, attr) 439 ipdb> print obj plain ipdb> print attr markup ipdb> print type(obj) It looks like the 'text' object access is one level off, since it's trying to get 'markup' from 'plain', which is the *value* of 'text.markup' in the traits description. This is with a just-built SVN. If any of you could look into this (I can't really hack on it right now) it would be great, since we can look at the performance issues with the Enthought team, but we need the code to actually run. If Eric/Darren want to talk directly, write to me off-list and I can call you on a phone. Cheers, f - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experimental, traited config module available in svn
Fernando, Thanks for taking the opportunity of checking into this now. I have to pass the buck, though--the bug you ran into looks like the intersection between Mike's extensive mathtext work and Darren's experimental replacement rc system, and apart from the testing you refer to (prior to much of Mike's work) I have not dealt with either of these areas. Eric Fernando Perez wrote: > Hi guys, > > [ For the Enthought gang, sorry for the cross-post. This is the context: > > http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/msg01451.html > > We're trying to see if it would be reasonable to use Traits for the > matplotlib config description, but there seem to be performance > issues. > ] > > On 7/31/07, Eric Firing <[EMAIL PROTECTED]> wrote: >> Darren, >> >> The two cases you ran have almost identical timing, so the problem is >> not in reading matplotlib.conf. Instead, it seems to be in the >> initialization of all the machinery, and I suspect that something may >> be getting run many times in a loop instead of just once. I used the >> profile.py script method to profile the whole simple_plot.py demo >> modified to use Agg, with NEWCONFIG True versus False. Attached are the >> top 100 lines of the output, sorted by cumulative time, with "new" >> meaning NEWCONFIG=True. The execution time of the new version is 3.2 >> seconds versus 1.8 for the old. (Both are pretty slow for making a >> minimal plot from a script.) >> > > I'm here at scipy'07 with the Enthought folks and trying to see if we > can understand what the issue with this traits startup cost is. But I > tried (with current SVN) to run a simple > > python -c 'import pylab;pylab.plot([1,2,3])' > > but I'm gettting: > > obj: plain > Traceback (most recent call last): > File "", line 1, in > File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/pylab.py", > line 2061, in plot > b = ishold() > File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/pylab.py", > line 888, in ishold > return gca().ishold() > File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/pylab.py", > line 834, in gca > ax = gcf().gca(**kwargs) > File > "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/figure.py", > line 722, in gca > return self.add_subplot(111, **kwargs) > File > "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/figure.py", > line 542, in add_subplot > a = Subplot(self, *args, **kwargs) > File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axes.py", > line 5157, in __init__ > self.figW, self.figH], **kwargs) > File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axes.py", > line 507, in __init__ > self._init_axis() > File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axes.py", > line 545, in _init_axis > self.xaxis = maxis.XAxis(self) > File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axis.py", > line 512, in __init__ > self.label = self._get_label() > File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axis.py", > line 990, in _get_label > horizontalalignment='center', > File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/text.py", > line 178, in __init__ > self.set_markup(markup) > File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/text.py", > line 780, in set_markup > self._markup = rcParams['text.markup'] > File > "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/config/mplconfig.py", > line 438, in __getitem__ > return getattr(obj, attr) > AttributeError: 'str' object has no attribute 'markup' > > > where the crash is coming from this (run interactively in ipdb): > > /home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/config/mplconfig.py > in __getitem__(self, key) > 436 obj, attr = self.tconfig_map[key] > 437 print 'obj:',obj > --> 438 return getattr(obj, attr) > 439 > 440 def keys(self): > > AttributeError: 'str' object has no attribute 'markup' > > In [2]: obj: MPLConfig > > > In [3]: debug >> /home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/config/mplconfig.py(438)__getitem__() > 437 print 'obj:',obj > --> 438 return getattr(obj, attr) > 439 > > ipdb> print obj > plain > ipdb> print attr > markup > ipdb> print type(obj) > > > > It looks like the 'text' object access is one level off, since it's > trying to get 'markup' from 'plain', which is the *value* of > 'text.markup' in the traits description. > > This is with a just-built SVN. > > If any of you could look into this (I can't really hack on it right > now) it would be great, since we can look at the performance issues > with the Enthought team, but we need the code to actually run. > > If Eric/Darren want to talk directly, write to me off-list and I can > call you on a phone. > > Cheers, > > f > > --
Re: [matplotlib-devel] Experimental, traited config module available in svn
On 8/16/07, Eric Firing <[EMAIL PROTECTED]> wrote: > Fernando, > > Thanks for taking the opportunity of checking into this now. I have to > pass the buck, though--the bug you ran into looks like the intersection > between Mike's extensive mathtext work and Darren's experimental > replacement rc system, and apart from the testing you refer to (prior to > much of Mike's work) I have not dealt with either of these areas. OK, understood. No worries. I'm rebuilding to SVN from August 1st, which is when this conversation started. That might do the trick and let us work here. I'll pester again for help if I get stuck. Regards, f - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experimental, traited config module available in svn
On Thursday 16 August 2007 03:15:39 pm Fernando Perez wrote: > On 8/16/07, Eric Firing <[EMAIL PROTECTED]> wrote: > > Fernando, > > > > Thanks for taking the opportunity of checking into this now. I have to > > pass the buck, though--the bug you ran into looks like the intersection > > between Mike's extensive mathtext work and Darren's experimental > > replacement rc system, and apart from the testing you refer to (prior to > > much of Mike's work) I have not dealt with either of these areas. > > OK, understood. No worries. > > I'm rebuilding to SVN from August 1st, which is when this conversation > started. That might do the trick and let us work here. I'll pester > again for help if I get stuck. Eric is correct. I have to run in a minute, but I'll update the config module early this evening to include Mikes recent changes. Thank you for bringing it up with Enthought, Fernando. Darren - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experimental, traited config module available in svn
On Thursday 16 August 2007 03:33:37 pm Darren Dale wrote: > On Thursday 16 August 2007 03:15:39 pm Fernando Perez wrote: > > On 8/16/07, Eric Firing <[EMAIL PROTECTED]> wrote: > > > Fernando, > > > > > > Thanks for taking the opportunity of checking into this now. I have to > > > pass the buck, though--the bug you ran into looks like the intersection > > > between Mike's extensive mathtext work and Darren's experimental > > > replacement rc system, and apart from the testing you refer to (prior > > > to much of Mike's work) I have not dealt with either of these areas. > > > > OK, understood. No worries. > > > > I'm rebuilding to SVN from August 1st, which is when this conversation > > started. That might do the trick and let us work here. I'll pester > > again for help if I get stuck. > > Eric is correct. I have to run in a minute, but I'll update the config > module early this evening to include Mikes recent changes. Fixed in svn 3711. gotta run! - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experimental, traited config module available in svn
On 8/16/07, Darren Dale <[EMAIL PROTECTED]> wrote:
> On Thursday 16 August 2007 03:33:37 pm Darren Dale wrote:
> > On Thursday 16 August 2007 03:15:39 pm Fernando Perez wrote:
> > > On 8/16/07, Eric Firing <[EMAIL PROTECTED]> wrote:
> > > > Fernando,
> > > >
> > > > Thanks for taking the opportunity of checking into this now. I have to
> > > > pass the buck, though--the bug you ran into looks like the intersection
> > > > between Mike's extensive mathtext work and Darren's experimental
> > > > replacement rc system, and apart from the testing you refer to (prior
> > > > to much of Mike's work) I have not dealt with either of these areas.
> > >
> > > OK, understood. No worries.
> > >
> > > I'm rebuilding to SVN from August 1st, which is when this conversation
> > > started. That might do the trick and let us work here. I'll pester
> > > again for help if I get stuck.
> >
> > Eric is correct. I have to run in a minute, but I'll update the config
> > module early this evening to include Mikes recent changes.
>
> Fixed in svn 3711. gotta run!
Mmh, I'm afraid not:
maqroll[config]> cat simple_plot.py
#!/usr/bin/env python
from pylab import plot, savefig
plot([1,2,3])
savefig('simple_plot')
maqroll[config]> python simple_plot.py
USING TRAITS!!!
Traceback (most recent call last):
File "simple_plot.py", line 4, in
plot([1,2,3])
File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/pylab.py",
line 2061, in plot
b = ishold()
File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/pylab.py",
line 888, in ishold
return gca().ishold()
File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/pylab.py",
line 834, in gca
ax = gcf().gca(**kwargs)
File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/figure.py",
line 722, in gca
return self.add_subplot(111, **kwargs)
File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/figure.py",
line 542, in add_subplot
a = Subplot(self, *args, **kwargs)
File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axes.py",
line 5157, in __init__
self.figW, self.figH], **kwargs)
File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axes.py",
line 507, in __init__
self._init_axis()
File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axes.py",
line 545, in _init_axis
self.xaxis = maxis.XAxis(self)
File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axis.py",
line 512, in __init__
self.label = self._get_label()
File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axis.py",
line 990, in _get_label
horizontalalignment='center',
File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/text.py",
line 178, in __init__
self.set_markup(markup)
File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/text.py",
line 780, in set_markup
self._markup = rcParams['text.markup']
File
"/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/config/mplconfig.py",
line 437, in __getitem__
return getattr(obj, attr)
AttributeError: 'str' object has no attribute 'markup'
This is with r3711
Cheers,
f
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experimental, traited config module available in svn
On Thursday 16 August 2007 5:25:47 pm Fernando Perez wrote: > On 8/16/07, Darren Dale <[EMAIL PROTECTED]> wrote: > > On Thursday 16 August 2007 03:33:37 pm Darren Dale wrote: > > > On Thursday 16 August 2007 03:15:39 pm Fernando Perez wrote: > > > > On 8/16/07, Eric Firing <[EMAIL PROTECTED]> wrote: > > > > > Fernando, > > > > > > > > > > Thanks for taking the opportunity of checking into this now. I > > > > > have to pass the buck, though--the bug you ran into looks like the > > > > > intersection between Mike's extensive mathtext work and Darren's > > > > > experimental replacement rc system, and apart from the testing you > > > > > refer to (prior to much of Mike's work) I have not dealt with > > > > > either of these areas. > > > > > > > > OK, understood. No worries. > > > > > > > > I'm rebuilding to SVN from August 1st, which is when this > > > > conversation started. That might do the trick and let us work here. > > > > I'll pester again for help if I get stuck. > > > > > > Eric is correct. I have to run in a minute, but I'll update the config > > > module early this evening to include Mikes recent changes. > > > > Fixed in svn 3711. gotta run! > > Mmh, I'm afraid not: Sorry, it should be fixed now. backend_driver.py runs all tests without any failures for me, using svn 3713. Here are my results on my computer at home, with the traited config disabled: Backend Agg took 1.82 minutes to complete template ratio 1.417, template residual 0.537 Backend PS took 1.64 minutes to complete template ratio 1.275, template residual 0.355 Backend Template took 1.29 minutes to complete template ratio 1.000, template residual 0.000 Backend SVG took 1.69 minutes to complete template ratio 1.313, template residual 0.403 and with the traited config enabled: Backend Agg took 1.98 minutes to complete template ratio 1.412, template residual 0.578 Backend PS took 1.95 minutes to complete template ratio 1.388, template residual 0.545 Backend Template took 1.41 minutes to complete template ratio 1.000, template residual 0.000 Backend SVG took 1.72 minutes to complete template ratio 1.226, template residual 0.318 That doesnt look too bad, compared to Eric's results. This is using a fresh traits installation, installed today with: sudo easy_install -f \ http://code.enthought.com/enstaller/eggs/source "enthought.traits < 3.0a" I dont know where to get the new eggs. I also tested it on my computer at work, which is 64bit, 4 processors, lots of ram, and SATA disks. Here are the results with traited config disabled: Backend Agg took 0.99 minutes to complete template ratio 1.639, template residual 0.386 Backend PS took 0.82 minutes to complete template ratio 1.364, template residual 0.220 Backend Template took 0.60 minutes to complete template ratio 1.000, template residual 0.000 Backend SVG took 0.77 minutes to complete template ratio 1.273, template residual 0.165 Here are the results with traited config enabled: Backend Agg took 1.10 minutes to complete template ratio 1.463, template residual 0.346 Backend PS took 0.97 minutes to complete template ratio 1.297, template residual 0.222 Backend Template took 0.75 minutes to complete template ratio 1.000, template residual 0.000 Backend SVG took 0.91 minutes to complete template ratio 1.220, template residual 0.165 Those results look fine to me. I dont know what has changed since we last discussed this, but when Eric brought up the speed issue I remember the traited config was significantly slower at that time. Maybe this is very good news! Darren - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Enthought-dev] Experiment al, traited config module available in svn
On Thursday 16 August 2007 7:20:57 pm Bryce Hendrix wrote: > Darren Dale wrote: > > On Thursday 16 August 2007 5:25:47 pm Fernando Perez wrote: > > > > ... > > > > Those results look fine to me. I dont know what has changed since we last > > discussed this, but when Eric brought up the speed issue I remember the > > traited config was significantly slower at that time. Maybe this is very > > good news! > > A lot of work has gone in to reducing the dependency on wx, perhaps > thats the cause for the improvement? Did you notice wx being imported > still? The only enthought packages that are installed on my machines are etsconfig and traits. Darren - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experimental, traited config module available in svn
Darren Dale wrote: > On Thursday 16 August 2007 5:25:47 pm Fernando Perez wrote: >> On 8/16/07, Darren Dale <[EMAIL PROTECTED]> wrote: >>> On Thursday 16 August 2007 03:33:37 pm Darren Dale wrote: On Thursday 16 August 2007 03:15:39 pm Fernando Perez wrote: > On 8/16/07, Eric Firing <[EMAIL PROTECTED]> wrote: >> Fernando, >> >> Thanks for taking the opportunity of checking into this now. I >> have to pass the buck, though--the bug you ran into looks like the >> intersection between Mike's extensive mathtext work and Darren's >> experimental replacement rc system, and apart from the testing you >> refer to (prior to much of Mike's work) I have not dealt with >> either of these areas. > OK, understood. No worries. > > I'm rebuilding to SVN from August 1st, which is when this > conversation started. That might do the trick and let us work here. > I'll pester again for help if I get stuck. Eric is correct. I have to run in a minute, but I'll update the config module early this evening to include Mikes recent changes. >>> Fixed in svn 3711. gotta run! >> Mmh, I'm afraid not: > > Sorry, it should be fixed now. backend_driver.py runs all tests without any > failures for me, using svn 3713. Here are my results on my computer at home, > with the traited config disabled: > > Backend Agg took 1.82 minutes to complete > template ratio 1.417, template residual 0.537 > Backend PS took 1.64 minutes to complete > template ratio 1.275, template residual 0.355 > Backend Template took 1.29 minutes to complete > template ratio 1.000, template residual 0.000 > Backend SVG took 1.69 minutes to complete > template ratio 1.313, template residual 0.403 > > and with the traited config enabled: > > Backend Agg took 1.98 minutes to complete > template ratio 1.412, template residual 0.578 > Backend PS took 1.95 minutes to complete > template ratio 1.388, template residual 0.545 > Backend Template took 1.41 minutes to complete > template ratio 1.000, template residual 0.000 > Backend SVG took 1.72 minutes to complete > template ratio 1.226, template residual 0.318 > > That doesnt look too bad, compared to Eric's results. This is using a fresh > traits installation, installed today with: > > sudo easy_install -f \ > http://code.enthought.com/enstaller/eggs/source "enthought.traits < 3.0a" > > I dont know where to get the new eggs. > > > I also tested it on my computer at work, which is 64bit, 4 processors, lots > of > ram, and SATA disks. Here are the results with traited config disabled: > > Backend Agg took 0.99 minutes to complete > template ratio 1.639, template residual 0.386 > Backend PS took 0.82 minutes to complete > template ratio 1.364, template residual 0.220 > Backend Template took 0.60 minutes to complete > template ratio 1.000, template residual 0.000 > Backend SVG took 0.77 minutes to complete > template ratio 1.273, template residual 0.165 > > Here are the results with traited config enabled: > > Backend Agg took 1.10 minutes to complete > template ratio 1.463, template residual 0.346 > Backend PS took 0.97 minutes to complete > template ratio 1.297, template residual 0.222 > Backend Template took 0.75 minutes to complete > template ratio 1.000, template residual 0.000 > Backend SVG took 0.91 minutes to complete > template ratio 1.220, template residual 0.165 > So, 10% slower with backend_agg, 18% slower with backend_svg. It's not devastating, but it's not so great, either. > Those results look fine to me. I dont know what has changed since we last > discussed this, but when Eric brought up the speed issue I remember the > traited config was significantly slower at that time. Maybe this is very good > news! > Maybe there is some sensitivity to machine architecture; my tests were on a Lenovo T60 laptop, Core2 at 2 GHz. For Fernando's simple_plot, using /usr/bin/time, I get: 0.53user 0.11system 0:00.66elapsed without traits 0.66user 0.21system 0:00.89elapsed with traits (The figures are quite repeatable; numbers above are representative. CPU is 98% in both cases.) So the total time for this very simple plot (which makes it something of a worst case) is more than 30% longer with traits than without, implying that the startup time increase is even larger as a percentage. One might argue that the difference of 0.23 seconds doesn't matter, but I think it is still worth considering. Maybe it can be beaten down to a small fraction of that. Other major chunks of the startup time are simply importing numpy and pylab. I don't know how much improvement is possible; maybe not much. I have already killed the biggest single contribution I could find, which was generation of the global FontManager instance. Now it is read from a pickle. Eric > Darren --
