Experimental, traited config module available in svn

Development matplotlib-devel
21

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

···

On 8/16/07, Eric Firing <efiring@...229...> 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.

22

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

···

On Thursday 16 August 2007 03:15:39 pm Fernando Perez wrote:

On 8/16/07, Eric Firing <efiring@...229...> 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.

23

Fixed in svn 3711. gotta run!

···

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 <efiring@...229...> 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.

24

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 <module>
    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

···

On 8/16/07, Darren Dale <dd55@...143...> 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 <efiring@...229...> 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!

25

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

···

On Thursday 16 August 2007 5:25:47 pm Fernando Perez wrote:

On 8/16/07, Darren Dale <dd55@...143...> 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 <efiring@...229...> 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:

26

Darren Dale 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

···

On Thursday 16 August 2007 5:25:47 pm Fernando Perez wrote:

On 8/16/07, Darren Dale <dd55@...143...> 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 <efiring@...229...> wrote:

Darren

27

Hi all,

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.

Here's some interesting info. I'm sitting here with Dave Peterson,
from Enthought, and we've done a bunch of profiling that pointed to
setuptools, not Traits, being the culprit for the time increase.
We've now just done an install of Traits *without* any setuptools
(right now that requires manual surgery, but later it can be done
automatically if needed). Here are the resulting times:

# Using traits

maqroll[mpl-traits-debug]> time ./simple_plot.py
*** Using Traits!!!
1.844u 0.212s 0:02.13 96.2% 0+0k 0+0io 0pf+0w
maqroll[mpl-traits-debug]> time ./simple_plot.py
*** Using Traits!!!
1.840u 0.216s 0:02.58 79.4% 0+0k 0+0io 0pf+0w
maqroll[mpl-traits-debug]> time ./simple_plot.py
*** Using Traits!!!
1.836u 0.196s 0:02.12 95.2% 0+0k 0+0io 0pf+0w

# NOT Using traits

maqroll[mpl-traits-debug]> time ./simple_plot.py
2.200u 0.280s 0:02.67 92.8% 0+0k 0+0io 0pf+0w
maqroll[mpl-traits-debug]> time ./simple_plot.py
2.248u 0.220s 0:02.74 89.7% 0+0k 0+0io 0pf+0w
maqroll[mpl-traits-debug]> time ./simple_plot.py
2.216u 0.244s 0:02.72 90.0% 0+0k 0+0io 0pf+0w

As you'll notice, the traits times are *lower*. This is what my gut
told me, since I know how tight the traits code is. The point is that
traits can actually give you a performance *benefit*, not a cost. The
problem is with setuptools, which goes ballistic on the filesystem at
init time. The profiles I sent earlier have already all the
information on that, if you use kcachegrind to see it (that's how Dave
and I pinned it down).

This hopefully settles the argument on the performance side. We'll
leave the final decision up to you guys, obviously. For IPython, this
settles the matter and we're going with traits, with setuptools banned
til further notice from ipython.

Cheers,

f

···

On 8/16/07, Eric Firing <efiring@...229...> wrote:

28

Thank you Dave and Fernando for getting to the bottom of this.

A lot of work has gone in to making mpl compatible with setuptools. In fact,
we require it to install on python-2.3. Are the setuptools developers aware
of the problem?

Darren

···

On Saturday 18 August 2007 12:44:20 pm Fernando Perez wrote:

Here's some interesting info. I'm sitting here with Dave Peterson,
from Enthought, and we've done a bunch of profiling that pointed to
setuptools, not Traits, being the culprit for the time increase.
We've now just done an install of Traits *without* any setuptools
(right now that requires manual surgery, but later it can be done
automatically if needed). Here are the resulting times:

# Using traits

maqroll[mpl-traits-debug]> time ./simple_plot.py
*** Using Traits!!!
1.844u 0.212s 0:02.13 96.2% 0+0k 0+0io 0pf+0w
maqroll[mpl-traits-debug]> time ./simple_plot.py
*** Using Traits!!!
1.840u 0.216s 0:02.58 79.4% 0+0k 0+0io 0pf+0w
maqroll[mpl-traits-debug]> time ./simple_plot.py
*** Using Traits!!!
1.836u 0.196s 0:02.12 95.2% 0+0k 0+0io 0pf+0w

# NOT Using traits

maqroll[mpl-traits-debug]> time ./simple_plot.py
2.200u 0.280s 0:02.67 92.8% 0+0k 0+0io 0pf+0w
maqroll[mpl-traits-debug]> time ./simple_plot.py
2.248u 0.220s 0:02.74 89.7% 0+0k 0+0io 0pf+0w
maqroll[mpl-traits-debug]> time ./simple_plot.py
2.216u 0.244s 0:02.72 90.0% 0+0k 0+0io 0pf+0w

As you'll notice, the traits times are *lower*. This is what my gut
told me, since I know how tight the traits code is. The point is that
traits can actually give you a performance *benefit*, not a cost. The
problem is with setuptools, which goes ballistic on the filesystem at
init time. The profiles I sent earlier have already all the
information on that, if you use kcachegrind to see it (that's how Dave
and I pinned it down).

This hopefully settles the argument on the performance side. We'll
leave the final decision up to you guys, obviously. For IPython, this
settles the matter and we're going with traits, with setuptools banned
til further notice from ipython.

29

In case anyone is interested, it looks like the new config package is working
with traits 3. This morning I uninstalled my enthought-2.whatever packages
and installed etsconfig-2.1 and traits-3 from enthought's svn trunk (using
the usual python setup.py install, not easy_install). backend_driver.py ran
without errors.

Darren