Darren Dale wrote:
On Monday 09 June 2008 04:04:47 pm Dave Peterson wrote:
Eric Firing wrote:
Dave Peterson wrote:
That said, given the upcoming release of Traits 3 this situation may
get a little crazier. T2 and T3 are not fully api compatible, though
they are very close. So I suspect version numbers are going to play
a larger role in the future. Is there anything we can do in the T3
release to make resolution of this upcoming issue easier to deal with
for the matplotlib team? One point probably worth mentioning is
that, IIRC, we currently rely on T3 being installed with egg
meta-data in order to determine an accurate version number.
Whether, or to what extent, mpl starts depending on traits is still
open; but if we do depend on it, I think we should simply require T3
as an external dependency. If that requires some slight modifications
of Darren's code, which was written for T2, I expect the changes will
be easy.
I think T2->T3 would not be a difficult transition for us. It may not even
require any modifications, I seem to remember the traited config stuff just
worked with traits3 last time I tried it, I just dont remember when I tried
it last.
Yes, the API breaks are not large at all. They're actually fairly
small, the bulk of the effort on T3 was behind the scenes and added
functionality. But there are some there so it may not be clear sailing
for everyone.
Three questions:
1) To what extent would the range of T3 eggs cover the various
platforms on which people run mpl?
Not quite sure on this one as I don't know what platforms are most used
by mpl. What I can say is that we've worked very hard to minimize the
dependencies Traits has on other things in order to make it as easy as
possible for people to install. We'll definitely be uploading a source
tarball, which should meet most people's needs, and a Windows binary
(since not all users there have a c compiler.) We may or may not put up
OS X, and a couple linux distribution, binaries.
2) For uncovered cases, should T3 be easy to build and install?
T3 proper needs a c compiler, gcc seems to work fine. TraitsGUI and the
backend projects seem to be pure-python though clearly you'll need libs
for the chosen backend.
3) My recollection is that setuptools was determined to be causing a
hit to the startup time, and mpl is already sluggish in starting up.
Is there any more insight or progress on this front? Is there a way
to use traits in mpl without increasing the startup time?
I'm not sure it was setuptools' egg features that were the problem so
much as I thought it was the use of namespace packaging we have embedded
all over in ETS. I don't see any significant efforts underway at this
time that are trying to speed this up, but perhaps I'm just uninformed
about any such efforts. I don't see anything on the horizon that would
let us remove this from the ETS projects either. The end result is I
don't see any way mpl could work around this and still treat Traits as
an external dependency.
Fernando saw a big performance hit due to namespace packaging, but I never saw
it. I think we concluded that the presence of large NFS mounts were causing
the performance hit in namespace packages that Fernando reported at Scipy
last year (Dave, was it you who worked with him?).
Yes, he and I sat together in a sprint room at Scipy and refactored
Traits code (and everything else using setuptools and namespace
packages) until we removed it all, taking timing runs each step of the
way. I'd actually be surprised if Fernando was using NSF mounts during
this effort, but I don't remember asking. I do remember him pointing
out how bad it *would* be for anyone using network drives to suffer
through some of the API call counts we saw when using namespace packages.
I did some profiling a while back also, after we added traits to the mpl
codebase and stripped out the namespace packaging. We still saw something
like a 30% performance hit, which I tracked back to regular expressions being
compiled in traits and in configobj. See:
http://thread.gmane.org/gmane.comp.python.enthought.devel/10908/focus=10989
I didn't intend to start up the root cause discussion again. :-) I only
wanted to point out that I hadn't heard of anyone working on improving
whatever performance problems exist / existed.
-- Dave
Darren
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
