Improving interpreter startup speed
bjourne at gmail.com
Wed Oct 29 14:35:36 CET 2008
2008/10/27 James Mills <prologic at shortcircuit.net.au>:
> On Mon, Oct 27, 2008 at 5:40 PM, David Cournapeau <cournape at gmail.com> wrote:
>> Depends on the tool: build tool and source control tools are example
>> it matters (specially when you start interfaciing them with IDE or
>> editors). Having fast command line tools is an important feature of
>> UNIX, and if you want to insert a python-based tool in a given
>> pipeline, it can hurt it the pipeline is regularly updated.
> Fair enough. But still:
> 0.5s old startup is fast enough
> 0.08s warm startup is fast enough.
> Often "fast enough" is "fast enough"
Nope, when it comes to start up speed the only thing that is fast
enough is "instantly." :) For example, if I write a GUI text editor in
Python, the total cold start up time might be 1500 ms on a cold
system. 750 ms for the interpreter and 750 ms for the app itself.
However, if I also have other processes competing for IO, torrent
downloads or compilations for example, the start up time grows
proportional to the disk load. For example, if there is 50% constant
disk load, my app will start in 1.5 / (1 - 0.5) = 3 seconds (in the
best case, assuming IO access is allocated as efficiently as possible
when the number of processes grows, which it isn't). If the load is
75%, the start time becomes 1.5 / (1 - 0.75) = 6 seconds.
Now if the Python interpreters start up time was 200 ms, by apps start
up time with 75% disk load becomes (0.2 + 0.75) / (1 - 0.75) = 3.8
seconds which is significantly better.
More information about the Python-list