On 28 October 2012 18:22, Stefan Behnel <span dir="ltr"><<a href="mailto:stefan_ml@behnel.de" target="_blank">stefan_ml@behnel.de</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">How much of an<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
effect would it have on startup times and these benchmarks if<br>
Cython-compiled extensions were used?<br>
</blockquote>
<br></div>
Depends on what and how much code you use. If you compile everything into one big module that "imports" all of the stdlib when it gets loaded, you'd likely loose a lot of time because it would take a while to initialise all that useless code on startup. If you keep it separate, it would likely be a lot faster because you avoid the interpreter for most of the module startup.<br>
</blockquote><div><br></div><div>I was specifically thinking in terms of the tests Brett ran (that was the full set on <a href="http://speed.python.org">speed.python.org</a>, wasn't it?), and having each stdlib module be its own extension i.e. no big import module. A literal 1:1 replacement where possible.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">I'm thinking here of elimination of .pyc interpretation and execution (stat<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

calls would be similar, probably slightly higher).<br>
</blockquote>
<br></div>
CPython checks for .so files before looking for .py files and imports are absolute by default in Py3, so there should be a slight reduction in stat calls. The net result then obviously also depends on how fast your shared library loader and linker is, etc., but I doubt that that path is any slower than loading and running a .pyc file.<br>
</blockquote><div><br></div><div>D'oh. I knew that and still got it backwards.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To be clear - I'm *not* suggesting Cython become part of the required build<br>
toolchain. But *if* the Cython-compiled extensions prove to be<br>
significantly faster I'm thinking maybe it could become a semi-supported<br>
option (e.g. a HOWTO with the caveat "it worked on this particular system").<br>
</blockquote>
<br></div>
Sounds reasonable.</blockquote><div><br></div><div>I think a stdlib compile script + pre-packaged hints for the 3.3 release would likely help both 3.3 and Cython acceptance.</div><div><br></div><div>Putting aside my development interest and looking at it purely from the PoV of a Python *user*, I'd really like to see Cython on <a href="http://speed.python.org">speed.python.org</a> eventually (in two modes - one without hints as a baseline and one with hints). Of course the ideal situation would be to have every implementation of Python 3.3 that is capable of running on the hardware contributing numbers e.g. if/when Jython achieves 3.3 compatibility I'd love to see numbers for it.</div>
<div><br></div><div>Tim Delaney</div></div>