On Thu, Jan 21, 2010 at 18:32, Collin Winter <collinwin...@google.com> wrote: > I added startup benchmarks for Mercurial and Bazaar yesterday > (http://code.google.com/p/unladen-swallow/source/detail?r=1019) so we > can use them as more macro-ish benchmarks, rather than merely starting > the CPython binary over and over again. If you have ideas for better > Mercurial/Bazaar startup scenarios, I'd love to hear them. The new > hg_startup and bzr_startup benchmarks should give us some more data > points for measuring improvements in startup time.
Sounds good! I seem to remember from a while ago that you included the Mercurial test suite in your performance tests, but maybe those were the correctness tests rather than the performance tests (or maybe I'm just mistaken). I didn't see any mention of that in the proto-PEP, in any case. > One idea we had for improving startup time for apps like Mercurial was > to allow the creation of hermetic Python "binaries", with all > necessary modules preloaded. This would be something like Smalltalk > images. We haven't yet really fleshed out this idea, though. Yeah, that might be interesting. I think V8 can do something similar, right? One problem we've had with using py2exe on Windows is that it makes it kind of a pain to properly support our extension/hooks mechanism (which pretty much relies on importing stuff), so that would have to be fixed somehow (I think py2exe apps don't have anything outside their library.zip in the PYTHONPATH, or something like that). What I personally would consider interesting for the PEP is a (not too big) section evaluating where other Python-performance efforts are at. E.g. does it make sense to propose a u-s merge now when, by the time 3.3 (or whatever) is released, there'll be a very good PyPy that sports memory usage competitive for embedded development (already does right now, I think) and a good tracing JIT? Or when we can compile Python using Cython, or Shedskin -- probably not as likely; but I think it might be worth assessing the landscape a bit before this huge change is implemented. Cheers, Dirkjan P.S. Is there any chance of LLVM doing something like tracing JITs? Those seem somewhat more promising to me (even though I understand they're quite hard in the face of Python features like stack frames). _______________________________________________ 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
