[Python-Dev] requirements for moving __import__ over to importlib?

[Brett Cannon]

On Tue, Feb 7, 2012 at 18:08, Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Tue, 7 Feb 2012 17:16:18 -0500
> Brett Cannon <brett at python.org> wrote:
> >
> > >  > IOW I really do not look forward to someone saying "importlib is so
> much
> > > > slower at importing a module containing ``pass``" when (a) that never
> > > > happens, and (b) most programs do not spend their time importing but
> > > > instead doing interesting work.
> > >
> > > Well, import time is so important that the Mercurial developers have
> > > written an on-demand import mechanism, to reduce the latency of
> > > command-line operations.
> > >
> >
> > Sure, but they are a somewhat extreme case.
>
> I don't think Mercurial is extreme. Any command-line tool written in
> Python applies. For example, yum (Fedora's apt-get) is written in
> Python. And I'm sure many people do small administration scripts in
> Python. These tools may then be run in a loop by whatever other script.
>
> > > But it's not only important for Mercurial and the like. Even if you're
> > > developing a Web app, making imports slower will make restarts slower,
> > > and development more tedious in the first place.
> > >
> > >
> > Fine, startup cost from a hard crash I can buy when you are getting 1000
> > QPS, but development more tedious?
>
> Well, waiting several seconds when reloading a development server is
> tedious. Anyway, my point was that other cases (than command-line
> tools) can be negatively impacted by import time.
>
> > >  > So, if there is going to be some baseline performance target I need
> to
> > > hit
> > > > to make people happy I would prefer to know what that (real-world)
> > > > benchmark is and what the performance target is going to be on a
> > > non-debug
> > > > build.
> > >
> > > - No significant slowdown in startup time.
> > >
> >
> > What's significant and measuring what exactly? I mean startup already
> has a
> > ton of imports as it is, so this would wash out the point of measuring
> > practically anything else for anything small.
>
> I don't understand your sentence. Yes, startup has a ton of imports and
> that's why I'm fearing it may be negatively impacted :)
>
> ("a ton" being a bit less than 50 currently)
>

So you want less than a 50% startup cost on the standard startup benchmarks?


>
> > This is why I said I want a
> > benchmark to target which does actual work since flat-out startup time
> > measures nothing meaningful but busy work.
>
> "Actual work" can be very small in some cases. For example, if you run
> "hg branch" I'm quite sure it doesn't do a lot of work except importing
> many modules and then reading a single file in .hg (the one named
> ".hg/branch" probably, but I'm not a Mercurial dev).
>
> In the absence of more "real world" benchmarks, I think the startup
> benchmarks in the benchmarks repo are a good baseline.
>
> That said you could also install my 3.x port of Twisted here:
> https://bitbucket.org/pitrou/t3k/
>
> and then run e.g. "python3 bin/trial -h".
>
> > I would get more out of code
> > that just stat'ed every file in Lib since at least that did some work.
>
> stat()ing files is not really representative of import work. There are
> many indirections in the import machinery.
> (actually, even import.c appears quite slower than a bunch of stat()
> calls would imply)
>
> > > - Within 25% of current performance when importing, say, the "struct"
> > >  module (Lib/struct.py) from bytecode.
> > >
> >
> > Why struct? It's such a small module that it isn't really a typical
> module.
>
> Precisely to measure the overhead. Typical module size will vary
> depending on development style. Some people may prefer writing many
> small modules. Or they may be using many small libraries, or using
> libraries that have adoptes such a development style.
>
> Measuring the overhead on small modules will make sure we aren't overly
> confident.
>
> > The median file size of Lib is 11K (e.g. tabnanny.py), not 238 bytes
> (which
> > is barely past Hello World). And is this just importing struct or is this
> > from startup, e.g. ``python -c "import struct"``?
>
> Just importing struct, as with the timeit snippets in the other thread.


 OK, so less than 25% slowdown when importing a module with pre-existing
bytecode that is very small.

And here I was worrying you were going to suggest easy goals to reach for.
;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120208/98ea1393/attachment.html>