At 10:27 PM 11/22/2005 +0100, M.-A. Lemburg wrote: >Every single time you fire up Python and the user has not >installed a module called "sitecustomize" (which is deliberatly >not shipped with Python), Python will scan the complete sys.path >for this module... and that's just one example.
Hm, I did forget about sitecustomize in this case. >It is rather common in Python code to test for the availability >of a faster variant by trying an import (e.g. for XML parsers) >and then falling back to some slower emulations. But a failed import is hardly a fast operation even with only a handful of directories on sys.path, so I don't see where this is hurting anything. In fact, if it's "rather common", then even the zip directory read cost is amortized over a larger total number of operations. > > Note by the way that "scan all these ZIP files" is a misleading term in > any > > case - the files are not "scanned". They are opened, and a small > amount of > > data is read from the end of the file. Nothing that I would consider > > "scanning" is involved. > >The data read from the end of the file is the directory >which is decoded using marshal functions. You normally >call this scanning data. Well, *I* normally wouldn't call it scanning, I'd call it reading, decoding, or marshalling. Scanning would be *looking* for something, versus reading and decoding a contiguous block of data at a well-known location. But oh well. >In summary, things get slower when importing from ZIP files; >it really only makes sense for applications that have a long >run time and where startup is not that important, e.g. >Zope et al. I'm terribly curious what Python applications exist for whom: 1. Startup time is a consideration, that 2. Haven't already been refactored to a long-running process. The only thing that occurs to me as even a possibility would be some kind of frequently-used system administration utility, like if you were going to rewrite all the bash builtin commands as Python scripts. (And no, I'm not being sarcastic, I really *am* curious about what kind of tools this would be an actual issue for.) >The main argument for using ZIP imports is to easy >distribution of complete pure-Python packages, not >a performance gain. You'd use one of the freeze tools >for that, e.g. mxCGIPython which creates a single >file Python interpreter which has a really good >startup time due to the fact that the Python lib >is embedded into the Python executable as static data >and then loaded on demand by the OS as needed. Then why was the python##.zip entry added to sys.path in Python 2.3? My understanding was that it was added to allow Python to start faster by cutting down on extraneous stat() calls. _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
