Guido van Rossum wrote: > Just to add some skepticism, has anyone done any kind of > instrumentation of bzr start-up behavior? IIRC every time I was asked > to reduce the start-up cost of some Python app, the cause was too many > imports, and the solution was either to speed up import itself (.pyc > files were the first thing ever that came out of that -- importing > from a single .zip file is one of the more recent tricks) or to reduce > the number of modules imported at start-up (or both :-). Heavy-weight > frameworks are usually the root cause, but usually there's nothing > that can be done about that by the time you've reached this point. So, > amen on the good luck, but please start with a bit of analysis.
This problem (slow application startup times due to too many imports at startup, which can in turn can be due to top level imports for library or framework functionality that a given application doesn't actually use) is actually the main reason I sometimes wish for a nice, solid lazy module import mechanism that manages to avoid the potential deadlock problems created by using import statements inside functions. Providing a clean API and implementation for that functionality is a pretty tough nut to crack though, so I'm not holding my breath... Cheers, Nick. P.S. It's only an occasional fairly idle wish for me though, or I'd have at least tried to come up with something myself by now. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ 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
