Home Original page

[Python-Dev] python process creation overhead

Gregory Szorc gregory.szorc at gmail.com
Tue May 13 22:58:05 CEST 2014 
On 5/12/2014 8:43 PM, Nick Coghlan wrote:
> On 13 May 2014 10:19,  <dw+python-dev at hmmz.org> wrote:
>> On Mon, May 12, 2014 at 04:22:52PM -0700, Gregory Szorc wrote:
>> 
>>> Why can't Python start as quickly as Perl or Ruby?
>> 
>> On my heavily abused Core 2 Macbook with 9 .pth files, 2.7 drops
>> from 81ms startup to 20ms by specifying -S, which disables
>> site.py.
>> 
>> Oblitering the .pth files immediately knocks 10ms off regular
>> startup. I guess the question isn't why Python is slower than
>> perl, but what aspects of site.py could be cached, reimplemented,
>> or stripped out entirely.  I'd personally love to see .pth
>> support removed.
> 
> The startup code is currently underspecified and underdocumented,
> and quite fragile as a result. It represents 20+ years of organic
> growth without any systematic refactoring to simplify and
> streamline things.
> 
> That's what PEP 432 aims to address, and is something I now expect
> to have time to get back to for Python 3.5. And yes, one thing
> those changes should enable is the creation of system Python
> runtimes on Linux that initialise faster than the current
> implementation.

This is terrific news and something I greatly anticipate taking
advantage of!

But the great many of us still on 2.7 likely won't see a benefit,
correct? How insane would it be for people to do things like pass -S
in the shebang and manually implement the parts of site.py that are
actually needed?
More information about the Python-Dev mailing list