On Tue, Feb 7, 2012 at 18:08, Antoine Pitrou <solip...@pitrou.net> wrote:
> 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) > 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. ;)
_______________________________________________ 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