[Python-Dev] imputil speed (was: .DLL vs .PYD search order)
M.-A. Lemburg
mal@lemburg.com
Sat, 04 Dec 1999 12:53:33 +0100
Greg Stein wrote:
> > > [me:]
> > > A chain of simple minded importers won't work together
> > > too well
> >
> > why? it sure works for us...
>
> Exactly. "Why?" Please provide an example.
See my reply to Fredrik.
> >...
> > > and downgrade performance considerably due to the
> > > many recursive function calls
> >
> > now that's what I call premature optimization. and this
> > scares the hell out of me: if the rest of the python-dev
> > crowd don't seriously believe that Python is (or can be
> > made) fast enough to implement things like this, why
> > the heck are you using Python at all? am I the only
> > one here who doesn't believe in osterhout's talk about
> > "the great system vs. scripting language divide"?
>
> Don't worry Fredrik... I'm with you on this one. I do not believe there is
> a problem with the speed. Nobody has yet profiled imputil to find out
> where/how the time is being spent. Nobody has tried to speed it up.
Sorry, Greg, but that is simply not true. I've spend a few
days on trying to get more performance out of it and have
succeeded, but in the end it wasn't enough to convince me
of the approach.
> Therefore, any claims about its performance are simply FUD.
BTW, did anybody mention that an import manager wouldn't
be able to provide an API which is useable for imputil
style importers ? I'm not argueing against the possibility
to use imputil style importers, just against making it the
sole method of adding wisdom to Python imports.
The imputil importers could well benefit from a manager
providing logic to do basic things like importing
shared libs, checking signatures, downloading modules
from the web, etc.
--
Marc-Andre Lemburg
______________________________________________________________________
Y2000: 27 days left
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/