[Python-Dev] Rethinking intern() and its data structure (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Fri Apr 10 10:52:40 CEST 2009

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 | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list