On Tue, 7 Feb 2012 17:16:18 -0500
Brett Cannon <br...@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)
> 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.
Regards
Antoine.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
