Hi Dirkjan, On Wed, Jan 20, 2010 at 10:55 PM, Dirkjan Ochtman <dirk...@ochtman.nl> wrote: > On Thu, Jan 21, 2010 at 02:56, Collin Winter <collinwin...@google.com> wrote: >> Agreed. We are actively working to improve the startup time penalty. >> We're interested in getting guidance from the CPython community as to >> what kind of a startup slow down would be sufficient in exchange for >> greater runtime performance. > > For some apps (like Mercurial, which I happen to sometimes hack on), > increased startup time really sucks. We already have our demandimport > code (I believe bzr has something similar) to try and delay imports, > to prevent us spending time on imports we don't need. Maybe it would > be possible to do something like that in u-s? It could possibly also > keep track of the thorny issues, like imports where there's an except > ImportError that can do fallbacks.
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. 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. Thanks, Collin Winter _______________________________________________ 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
