<br><br><div class="gmail_quote">On Sat, Oct 27, 2012 at 4:40 PM, Mark Shannon <span dir="ltr"><<a href="mailto:mark@hotpy.org" target="_blank">mark@hotpy.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On 27/10/12 20:21, Antoine Pitrou wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sat, 27 Oct 2012 09:20:36 -0400<br>
Brett Cannon <<a href="mailto:bcannon@gmail.com" target="_blank">bcannon@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I did check that markup safe as not installed. It might just be mako doing<br>
something silly.<br>
<br>
The threads tests are very synthetic.<br>
<br>
And yes, there are more modules at startup. When was the last to,e we<br>
looked at them to make sure we weren't doing needless I ports?<br>
</blockquote>
<br>
The last time was between 3.2 and 3.3. It will be hard to lower the<br>
number of imported modules, given the current semantics (io, importlib,<br>
unicode, site.py, sysconfig...). Python 2's view of the world was much<br>
simpler (naïve?) in comparison.<br>
<br>
It would be interesting to know *where* the module import time gets<br>
spent, on a lower level. My gut feeling is that execution of Python<br>
module code is the main contributor.<br>
</blockquote>
<br></div>
I suspect that stating and loading the .pyc files is responsible for most of the overhead.<br></blockquote><div><br></div><div>I really doubt that as the amount of stat calls is significantly reduced in Python 3.3 compared to Python 3.2 (startup benchmarks show Python 3.3 is roughly 1.66x faster than 3.2 thanks to caching filenames in a directory). More modules means more work (e.g. I/O, executing the module, etc.).</div>

<div><br></div><div>The only way to lower stat call overhead is to simply not check if a directory's contents changed during startup by assuming Python itself will not write any new module files. Without benchmarking I don't know if it would make that much of a difference, though.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
PyRun starts up quite a lot faster thanks to embedding all the modules in the executable: <a href="http://www.egenix.com/products/python/PyRun/" target="_blank">http://www.egenix.com/<u></u>products/python/PyRun/</a><br>


<br>
Freezing all the core modules into the executable should reduce start up time.<br></blockquote><div><br></div><div> Sure, but working with a frozen module is a pain so it is not something to take lightly.</div></div>