Python startup time: milliseconds matter

I&#x27;ve always been disappointed by how large software projects, both FOSS and commercial, lose their &quot;can do&quot; spirit with age. Long-time contributors become very quick with a &quot;no&quot;. They dismiss longstanding problems as illegitimate use cases and reject patches with vague and impervious arguments about &quot;maintainability&quot; or &quot;complexity&quot;. Maybe in some specific cases these concerns might be justified, but when everything garners this reaction, the overall effect is that progress stalls, crystallized at the moment the last bit of technical boldness flowed away.<p>You can see this attitude of &quot;no&quot; on this very HN thread. Read the comments! Instead of talking about ways we can make Python startup faster, we&#x27;re seeing arguments that Python shouldn&#x27;t be fast, we shouldn&#x27;t try to make it faster, and that programs (and, by implication, programmers) who want Python startup to be fast are somehow illegitimate. It&#x27;s a dismal perspective. We should be exercising our creativity as a way to solve problems, not finding creative ways to convince ourselves to accept mediocrity.

I have to say that my first reaction was: &quot;maybe you shouldn&#x27;t use python for this, then&quot;. If you are using a language in a way that it gets worse in subsequent versions, that&#x27;s a good sign that they&#x27;re optimizing for something other than what you care about.<p>The programming language R does not, as I understand it, optimize for speed, because they are optimizing for ease of exploratory data analysis. R is growing quite rapidly. So is python, actually. It doesn&#x27;t mean that either one is good at everything, and it&#x27;s probably the case that both are growing because they don&#x27;t try to be good at everything. A good toolbox is better than a multi-tool.

I totally understand that milliseconds matter in the use case described in the article.<p>For me, personally, I use python to automate tasks - or to quickly parse through loads and loads of data. To me, startup speed is <i>somewhat</i> irrelevant.<p>I built a micro-framework that is completely unorthodox in nature, but very effective for what I needed - that being a suite of tools available from an &#x27;internet&#x27; server, available to me (and my coworkers) over port 80 or 443.<p>My internet server, which runs python on the backend (and uses apache to actually serve the GET &#x2F; POST) literally spits out pages in 0.012 seconds. Some of the &#x27;tools&#x27; run processes on the system, reach out to other resources, and spit the results out in under 0.03 seconds (much of that being network &#x2F; internet RTT). To me, that&#x27;s <i>good enough</i> - adding 30 or even 300 milliseconds to any of that just wouldn&#x27;t matter.<p>I totally get that if Python wants to be a big (read bigger?) player then startup time matters more...but for my personal use cases, I&#x27;m not concerned with the current startup time one bit.

Sort of related story: we needed a scripting language able to run on an x86 RTOS type of architecture compiled with msvc and looked into CPython because, well, Python is after all quite a nice language. After spending a considerable amount of time to get it compiled (sorry, don&#x27;t recall all the issues there, but main one was that the source code assumed msvc == windows which I know is true for 99% of cases but didn&#x27;t expect a huge project like CPython to trip over) it would segfault at startup. During step-by-step debugging it was astonishing how much code got executed before even doing some actual interpreting&#x2F;REPL. Now I get there might not be a way around some initialization, but still it simply looked too much to me and perhaps not overly clean either. Moreover it included a bunch of registry access (again, because it saw msvc baing used) which the RTOS didn&#x27;t have in full hence the segfault. Anyway we looked further and thankfully found MicroPython which took less time to port than the time spend to get CPython even compiling. While not a complete Python implementation, it does the job fur us, and it gets away with startup&#x2F;init code of just something like 100 LOC (including argument parsing etc). Yes I know it&#x27;s not a fair comparision, but still, the difference is big enough to, at least for me, indicate CPython might just be doing too much at startup and&#x2F;or possibly spend time on features which aren&#x27;t used by many users and&#x2F;or possibly drags along some old cruft. Not sure, just guessing.

Mercurial&#x27;s startup time is the reason why, for fish, I&#x27;ve implemented code to figure out if something might be a hg repo myself.<p>Just calling `hg root` takes 200ms with hot cache. The equivalent code in fish-script takes about 3. Which enables us to turn on hg integration in the prompt by default.<p>The equivalent `git rev-parse` call takes about 8ms.

This is truly a problem. Even more so if you host your application on a network directory. Loading all the small files takes ages. I really wish there would be a good way to compile the whole application with all the modules into one package once you&#x27;re ready to release. I really wish the creators of Python would have given such use-cases more consideration.<p>Edit: I&#x27;m aware that there are solutions that put everything a program touches into a kind of executable archive. A single file several hundred Megabytes in size. I&#x27;ve tested it. It doesn&#x27;t really pre-compile the modules. The startup time was exactly the same.

Here&#x27;s what has worked for me:<p>1. Don&#x27;t do that. Either write the driving app in Python or write the subprocesses in an ahead-of-time compiled language. Python&#x27;s a great language but it&#x27;s not the right tool for everything.<p>2. Be parsimonious with the modules you import. During development, measure the performance after adding new imports. E.g., one graph libraries I tried had all its many graph algorithm implementations separated into modules and it loaded every single one of them even if all you wanted to do was to create a data structure and do some simple operations on it. We just wrote our own minimal class.

The slow startup combined with the general lack of interest of the Python ecosystem to try to find a solution for distributing self contained applications was the biggest reason we ended up writing out CLI tool in something else even though we are a Python shop.<p>I&#x27;m really curious why there hasn&#x27;t been much of a desire to change this and it even got worse as time progressed which is odd.

Best out of 5 times on my Debian testing laptop for a &quot;hello world&quot;, in order of worst to best:<p><pre><code> ruby2.5: 83ms (-e &#x27;puts &quot;hi&quot;&#x27;) python3.6: 35ms (-c &#x27;print(&quot;hi&quot;)&#x27;) python2.7: 24ms (-c &#x27;print(&quot;hi&quot;)&#x27;) perl5.26.2: 8ms (-e &#x27;print &quot;hi&quot;&#x27;) C (GCC 7.3): 2ms (int main(void) { puts(&quot;hi&quot;); })</code></pre>

<p><pre><code> in the temple of tmux for the cult of vi we sit and wait for venv to activate</code></pre>

Given it is known how slow Python at starting up, I am puzzled why Mozilla continue to use it in build scripts. Perl is just as portable but starts up like 10 times faster.

Naive question: If the startup time matters because you&#x27;re imposing that startup time hundreds or thousands of times - why not remove the startup time?<p>I&#x27;m saying, use the emacs model. Start hg with a flag so it simply keeps running in the background while listening on a port. Run a bare-bones nc script to pipe commands to hg over a port and have it execute your commands.<p>This isn&#x27;t a new problem, nor is it even a new solution. No complete re-write of the interpreter or the tool required.<p>Anyways, that&#x27;s my 2¢

I hate to admit it but it&#x27;s partly why I don&#x27;t use clojure (pardon the side-topic) more. I can&#x27;t bear the boot process and the overall cost.<p>Python is free to tinker, and all similar interpreters are joyful to use. Anything else is probably better for heavy duty jobs environments.

Knock, Knock, who&#x27;s there? ---- Long Pause --- Java!

Python is great for prototyping or even real apps if performance isn&#x27;t so critical. However, more than once I&#x27;ve found myself in the situation where I wrote a bunch of Python code and then end up starting that code up from another app, just like the thread discusses and I immediately feel like this is an anti-pattern.<p>What&#x27;s even more annoying is that my Python code usually calls a whole lot of C libraries (OpenCV, numpy, etc.) So it&#x27;s like this: app-&gt;OS process-&gt;python interpreter-&gt;my python code-&gt;C libraries. That just really feels wrong so I&#x27;d like two things:<p>1) better&#x2F;easier path to embed python scripts into my app e.g. resident interpreter<p>2) some way of passing scripts to python without restarting a new process, this may exist and I&#x27;m unaware

Startup time has also been the biggest gripe I have with Julia so far. Otherwise it&#x27;s a truly fantastic language to work in. I wasn&#x27;t able to put the `__precompile__()` function to good use it seems - the time it takes to execute my program didn&#x27;t change at all for some reason. Or maybe it&#x27;s not actually the startup time that caused the problem, but the time it took to perform file IO. Anyways my program now takes even much longer time to startup than the Python equivalent (though it runs much faster once started), which is a real disappointment.

Truly solving this problem is difficult, but you can hack around it with a zygote process to remove a substantial amount of overhead, in exchange for RAM. While this is generally more of win for server processes, you can see it applied to a CLI proof of concept:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;msolo&#x2F;pyzy" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;msolo&#x2F;pyzy</a>

I agree Python&#x27;s startup time is too slow. But one trick you can use to improve it some is the &quot;-S&quot; flag, which skips site-specific customizations. On my Ubuntu system it brings Python 3.6 startup time down from 36ms to 18ms for me; still not great, but it helps.<p>The drawback is this may screw up your Python environment, not sure how easy it is to work around it if it does.

Proposed solution: steal undump from emacs. <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=13073566" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=13073566</a><p>Perhaps it would be possible to read in the source files, compile them, and preserve an image of the state immediately before reading input or command line.

I was kind of amazed how penalized a script could be by collecting all its “import” statements at the top. Once somebody’s command couldn’t even print “--help” output in under 2 seconds, and after measuring the script I told them to move all their imports later and the docs appeared instantly.

I&#x27;m a long time python user, but never really peeked under the hood. However, I have a few ideas.<p>Optimized modules loading: maybe loading a larger &#x27;super&#x27; module would be faster than several smaller ones? For example a python program could be analyzed to find it&#x27;s dependent modules, and then pack all these into a &#x27;super&#x27; module.<p>Once the python program executes, it would load the single &#x27;super&#x27; module and hopefully bypass all the dynamic code which each module runs when imported to load up.<p>As mentioned previously, this is just off the top of my head and would certainly warrant more investigation&#x2F;profiling to confirm my hypothesis.

I&#x27;m pretty sure it&#x27;s too late by now for Python, but I&#x27;ve had some success with compiling C-based interpreters [0] to C; that is, generating the actual C code that the interpreter would execute to run the program. That way you can reuse much of the interpreter, keep the dynamic behavior and still get nimble native executables.<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;basic-gongfu&#x2F;cixl#compiling" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;basic-gongfu&#x2F;cixl#compiling</a>

Should be able to hot boot the VM with the right tooling. You can reuse HPC &quot;checkpoint&quot; code from supercomputing environments as a generic hammer for Python&#x2F;Ruby&#x2F;JVM. Some Russians figured out how to do it in userspace without a kernel mod: <a href="https:&#x2F;&#x2F;criu.org&#x2F;Main_Page" rel="nofollow">https:&#x2F;&#x2F;criu.org&#x2F;Main_Page</a>

People here comment about how python is slow, but even fast&#x2F;slow is I&#x27;ll defined in my opinion. You don&#x27;t see people hacking tensor flow (generally) in native languages to speed it up, they just enable CUDA. I&#x27;m imagining fast definition is limited to massively parallel server workloads with io.

Reminds me of buildout. It&#x27;s awful piece of software. We used in previous Flask project, and a simple flask shell takes 3 minutes to start. If you type `import` in CPython shell it will literally freeze for a few seconds. Because it injects one sys.path for each packages specified!!!

I&#x27;m just curious why more people don&#x27;t make use of chg to avoid the mercurial startup time. It seemed to solve it for me - are there drawbacks?

A recent article in ACM Queue included an off-hand remark that Go&#x27;s compile time is often faster than Python&#x27;s startup time. Just sayin&#x27;

Would it be feasible to keep a set of Python interpreters around at all times and use a round robin approach to feed each already-on interpreter commands then perform an interpreter environment cleanup out-of-band after a task is complete?

Slowness is the elephant in the room in Python land. It&#x27;s like everybody has decided to cover their eyes in front of this massive pachyderm. A massive delusion

It&#x27;s weird to see someone make this pitch when C systems software development regularly requires us to try and shave off microseconds. Millisecond delays mean you&#x27;ve already fucked up.

For use cases where performance is important, using an interpreted (implementation of a) language is a bad idea.<p>There are many great reasons to use Python, but execution speed is not one of them.

IIRC CPython devs reject performance-related patches if they cause the code to become &quot;less readable&quot;.<p>&gt;&gt; I believe Mercurial is, finally, slowly porting to Python 3.<p>I just gave up on Mercurial since it didn&#x27;t let me push to BitBucket nor to an Ubuntu VPS via SSH.<p>For better or worse, Git just works.