<br><br><div><span class="gmail_quote">On 6/11/07, <b class="gmail_sendername">Phillip J. Eby</b> &lt;<a href="mailto:pje@telecommunity.com">pje@telecommunity.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
At 12:46 AM 6/12/2007 +0200, Giovanni Bajo wrote:<br>&gt;Hi Philip,<br>&gt;<br>&gt;I&#39;m going to submit a PEP for Python 3000 (and possibly backported<br>&gt;as an option off by default in Python 2). It&#39;s related to imports
<br>&gt;and how to make them faster. Given your expertise on the subject,<br>&gt;I&#39;d appreciate if you could review my ideas. I briefly spoken of it<br>&gt;with Alex Martelli a few days ago at PyCon Italia and he was not
<br>&gt;negative about it.<br>&gt;<br>&gt;Problems:<br>&gt;<br>&gt;- A single import causes many syscalls (.pyo, .pyc, .py, in both<br>&gt;directory and .zip file).<br>&gt;- Situation is getting worse and worse with the advent of
<br>&gt;easy_install which produces many .pth files (longer sys.path).<br>&gt;- Python startup time is slow, and a noticable fraction of it is<br>&gt;dominated by site.py-related stuff (a simple hello world runs takes<br>
&gt;0.012s if run without -S, and 0.008s if run with -S).<br>&gt;- Many people might not be interested in this, but others are really<br>&gt;concerned. Eg: again at PyCon italia, I spoke with one of the<br>&gt;leading Sugar programmers (OLPC) who told me that one of the biggest
<br>&gt;blocker right now is the python startup time (applications on latest<br>&gt;OLPC prototype take 3-4 seconds to startup). He suggested that this<br>&gt;was related to the large number of syscalls made for imports.<br>
&gt;<br>&gt;<br>&gt;Proposed solution:<br>&gt;<br>&gt;- A site cache is introduced. It&#39;s a dictionary mapping module names<br>&gt;to absolute file paths.<br>&gt;- When an import occurs, for each directory/zipfile we walk in
<br>&gt;sys.path, we read all directory entries, and update the site cache<br>&gt;with all the Python modules found in it (all the Python modules<br>&gt;found in the directory/zipfile).<br>&gt;- If the filepath for a certain module is found in the site cache,
<br>&gt;the module is directly accessed. Otherwise, sys.path is walked.<br>&gt;- The site cache can be cleared with sys.clear_site_cache(). This<br>&gt;must be used after manual editing of sys.path (or could be done<br>&gt;automatically by making 
sys.path a list subclass which notices each<br>&gt;modification).<br>&gt;- The site cache must be manually cleared if a Python file is added<br>&gt;to a directory in sys.path after the application has started. This<br>&gt;is a rare-enough scenario to require an additional explicit call.
<br>&gt;- If for whatever reason a filepath found in the site cache cannot<br>&gt;be accessed (unmounted device, whatever) ImportError is raised.<br>&gt;Again, this is something which is very rare and does not require<br>
&gt;much attention.<br><br>Here&#39;s a simpler solution, one that&#39;s easily testable using existing<br>Python versions.&nbsp;&nbsp;Create a subclass of pkgutil.ImpImporter<br>(Python &gt;=2.5) that caches a listdir of its contents, and uses it to
<br>immediately reject any find_module() requests for which matching data<br>is not in its cached listdir.&nbsp;&nbsp;Add this class to sys.path_hooks, and<br>see if it speeds things up.</blockquote><div><br><br>I thought about this use case when writing importlib for lowering the penalty of importing over NFS and this is exactly how I would do it as well (except I would use the code from importlib instead of pkgutil&nbsp; =).
<br></div><br>-Brett<br></div>