23 ms·

Python startup time: milliseconds matter

662 points by vanni 8y ago

dingo_bat 8y ago
It'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've already fucked up.
est 8y ago
Reminds me of buildout. It'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!!!
area_man 8y ago
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: https://github.com/msolo/pyzy https://github.com/msolo/pyzy
beiller 8y ago
People here comment about how python is slow, but even fast/slow is I'll defined in my opinion. You don't see people hacking tensor flow (generally) in native languages to speed it up, they just enable CUDA. I'm imagining fast definition is limited to massively parallel server workloads with io.
YesThatTom2 8y ago
A recent article in ACM Queue included an off-hand remark that Go's compile time is often faster than Python's startup time. Just sayin'
falcolas 8y ago
Naive question: If the startup time matters because you're imposing that startup time hundreds or thousands of times - why not remove the startup time? I'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. This isn't a new problem, nor is it even a new solution. No complete re-write of the interpreter or the tool required. Anyways, that's my 2¢
- price 8y ago
  There's a paragraph in the OP about how they've actually done this: > Mercurial provides a `chg` program that essentially spins up a daemon `hg` process running a "command server" so the `chg` program [written in C - no startup overhead] can dispatch commands to an already-running Python/`hg` process and avoid paying the startup overhead cost. When you run Mercurial's test suite using `chg`, it completes minutes faster. `chg` exists mainly as a workaround for slow startup overhead. Just like this isn't what the usual `emacs` command does (it's `emacsclient`), it isn't what the usual `hg` command does either. There are some disadvantages to this solution and some assumptions it makes, which have apparently led the Mercurial maintainers to conclude, like the Emacs maintainers, that it won't work as the default. Hence the desire for solutions that will.
abk786 8y ago
dsaf
SZJX 8y ago
Startup time has also been the biggest gripe I have with Julia so far. Otherwise it's a truly fantastic language to work in. I wasn't able to put the `__precompile__()` function to good use it seems - the time it takes to execute my program didn't change at all for some reason. Or maybe it'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.
- ChrisRackauckas 8y ago
  precompile doesn't store native compiled code. Though I know from talking to the compiler developers that this is high on the 1.x list. It's an annoyance but at least it has a clear solution in sight.
crb002 8y ago
Should be able to hot boot the VM with the right tooling. You can reuse HPC "checkpoint" code from supercomputing environments as a generic hammer for Python/Ruby/JVM. Some Russians figured out how to do it in userspace without a kernel mod: https://criu.org/Main_Page https://criu.org/Main_Page
peterkelly 8y ago
For use cases where performance is important, using an interpreted (implementation of a) language is a bad idea. There are many great reasons to use Python, but execution speed is not one of them.
- std_throwaway 8y ago
  But what else do you switch to? Imagine you import tons of modules which often are only available in Python. This gets you going really quickly with your project and it runs very smoothly. Transferring this to C++ would probably take so long you won't even finish to find out before you run out of funding. I have hopes that Rust or some descendant of Rust will get us there in maybe 10 years but in the meantime it would be better to get Python up to speed as good as possible.
  - julvo 8y ago
    For some use cases, Go might be a good alternative to Python. It's performant, yet simple and readable and it has a great ecosystem.
    - std_throwaway 8y ago
      Do we have numpy, matplotlib, scipy, pickle etc. for Go?
      - jerf 8y ago
        Do the build processes mentioned in this email make heavy use of numpy, matplotlib, scipy, pickle, etc.? NumPy is very exciting and all, but it's a subcommunity of the Python community, not 90% of its usage. NumPy users are probably not, in general, trying to spawn twenty five thousand processes in sequence to accomplish some task. The people who are complaining about fractions of a millisecond of startup time are not inverting massive matrices.
        std_throwaway 8y ago
std_throwaway 8y ago
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're ready to release. I really wish the creators of Python would have given such use-cases more consideration. Edit: I'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've tested it. It doesn't really pre-compile the modules. The startup time was exactly the same.
- alexhutcheson 8y ago
  Check out subpar: https://github.com/google/subpar https://github.com/google/subpar
- sametmax 8y ago
  Nuikta (http://nuitka.net/ http://nuitka.net/) already does that and much more: - it compiles your program and make it stand alone so you can distribute just the exe - it makes it start faster - it makes it run faster - it's fully independant of the system python. Actually your system doesn't even need a python at all I don't get why it's not used, it's very robust, compatible with 3.6 and on some of my script I get about x4 speed up just on start up alone.
  - rhizome 8y ago
    Is it a perl2exe descendant, packing the interpreter into an executable wrapper?
    - sametmax 8y ago
      No it compiles python to C, then compile the C.
  - std_throwaway 8y ago
    This is different from the package that I've tested (PyInstaller or py2exe). Is Nuikta compatible with numpy, pickle, etc? I remember that numpy was very problematic with compilers like pypy for a long time.
2RTZZSro 8y ago
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?
- std_throwaway 8y ago
  I imagine this could be handled by some kind of "fork". Where you instantly duplicate the whole process with copy-on-write.
- tlrobinson 8y ago
  Or just use the operating system's `fork` system call? There's also nailgun for Java which sounds like it works a little differently: http://martiansoftware.com/nailgun/ http://martiansoftware.com/nailgun/
  - amelius 8y ago
    I guess a fork()'ed process triggers copy-on-write behavior in the kernel once the process starts running. So that's latency (the copying) you could still optimize away.
    - greglindahl 8y ago
      You might want to measure it before you optimize it! Oftentimes I find that forks where I don't write much are quite inexpensive, with little COW action.
      - amelius 8y ago
        You could be right. Also, could it be that Intel's cache hierarchy plays some really smart tricks behind the scenes, to make this fast?
    - hawski 8y ago
      I may be wrong, but I would bet that copy-on-write of pages would be hardly visible for most workloads. Copying is quite fast when you do it in batches (4k per page).
fpoling 8y ago
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.
- feedmeseymour 8y ago
  Perl is “just as portable” in the same way that a motorcycle can just as easily drive under a steamroller... it’s not gonna be pretty and there’s no easy way out if you do it.
  - ryl00 8y ago
    I write Perl scripts for Windows and Linux, and I don't find portability to be especially onerous. Of course there are platform differences to keep in mind, but is that any different from any other cross-platform scripting language?
- jdashg 8y ago
  Compile time is absolutely dominated by c++ (and now rust) compilation and linking. I doubt build system language choice will ever bubble up to relevance, so why optimize for it?
- ch4s3 8y ago
  I imagine there are two aspects to this, they probably started in python and have a lot of it already, and it's probably easier to gen new folks involved which I think is one of their goals.
- sametmax 8y ago
  I've built firefox from source. Python start up time is not really a problem, it's so long to build anything anyway.
  - kevincox 8y ago
    I imagine a lot of the pain is for incremental builds where the build system overheads can matter a lot more.
the_mitsuhiko 8y ago
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. I'm really curious why there hasn't been much of a desire to change this and it even got worse as time progressed which is odd.
- stevekemp 8y ago
  Indeed this is a long-standing issue with Python. LWN gave some excellent coverage late last year, in this piece: https://lwn.net/Articles/730915/ https://lwn.net/Articles/730915/
- fulafel 8y ago
  Sure there has been desire to change this. It's a hard problem, and there are tradeoffs.
  - the_mitsuhiko 8y ago
    It’s only a hard problem if there is no desire. The slowdowns for the interpreter startup did not happen because they are necessary but because site.py and friends just do more stuff now and a lot of important internal tooling became unnecessarily complex.
    - zbxxx 8y ago
      Yeah, this whole "importlib in Python" thing continues to mystify me.
      - pas 8y ago
        It would be okay, if Python would support a low level faster subPython within itself. RPython for example.
- sametmax 8y ago
  > it even got worse as time progressed which is odd. Quite the contrary, as I stated in my other comment, we now have nuikta.
deaps 8y ago
I totally understand that milliseconds matter in the use case described in the article. For me, personally, I use python to automate tasks - or to quickly parse through loads and loads of data. To me, startup speed is somewhat irrelevant. 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 'internet' server, available to me (and my coworkers) over port 80 or 443. My internet server, which runs python on the backend (and uses apache to actually serve the GET / POST) literally spits out pages in 0.012 seconds. Some of the 'tools' 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 / internet RTT). To me, that's good enough - adding 30 or even 300 milliseconds to any of that just wouldn't matter. 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'm not concerned with the current startup time one bit.
- cjhanks 8y ago
  As expected, language start up time only matters to some people. Often in my case, Python is used to build command line tools (similar to the case of Mercurial). In such an event, the start-up time of the program might dominate the total run time of the application. And on my laptop or desktop with a fast SSD with good caching and a reasonably fast CPU... that still ends up being 'okay'. But once I put that on an ARM chip with a mediocre hard drive - some python scripts spend so long initializing that they are practically unusable. Whereas the comparable Perl/BASH script runs almost instantaneously. Often to make Python even practically usable for such systems I have to implement my own lazily loaded module system. Having some language which allowed me to say... import(eager) some_module import(lazy) another_module Which could trigger the import process only when that module becomes necessary (if ever).
  - mywittyname 8y ago
    Have you tried moving import statements into the functions where they are invoked? My understanding is this is effectively the same as lazy loading the module[1]. [1] https://stackoverflow.com/questions/3095071/in-python-what-happens-when-you-import-inside-of-a-function https://stackoverflow.com/questions/3095071/in-python-what-h...
faho 8y ago
Mercurial's startup time is the reason why, for fish, I've implemented code to figure out if something might be a hg repo myself. 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. The equivalent `git rev-parse` call takes about 8ms.
- anonymouz 8y ago
  Somewhat tangentially, I noticed that fish performs quit badly in remote-mounted (sshfs) directories that are git repositories. I wonder if it would be possible to detect a remote mounted filesystem and turn off/tone down some of the round-trip heavy operations?
  - justusw 8y ago
    I've gone through your problem myself countless times, and concluded that hitting ctrl+c to interrupt the status line every time it tries to render the current repository state is not very productive. My git status line uses timelimit (https://devel.ringlet.net/sysutils/timelimit/ https://devel.ringlet.net/sysutils/timelimit/) to automatically stop if any of the git status parts (dirty/staged/new files) take > 0.1 seconds to finish: https://github.com/justuswilhelm/pufferfish/blob/master/fish/functions/git_status.fish https://github.com/justuswilhelm/pufferfish/blob/master/fish...
- majewsky 8y ago
  Wow, that's quite a difference. But 8ms is still too slow for me. :) I implemented the Git recognition code myself in my own prompt using the minimal amount of FS operations [1], and it renders in 5 ms from start to finish, including a "git:branch-name/47d72fe825" display. [1] https://github.com/majewsky/gofu/blob/master/pkg/prompt/git.go https://github.com/majewsky/gofu/blob/master/pkg/prompt/git....
  - avar 8y ago
    (I work on Git in my copious free time) One of the reasons git-rev-parse takes slightly longer than your implementation is that you just unconditionally truncate the SHA-1 to 10 bytes. E.g. run this on linux.git: git log --oneline --abbrev=10 --pretty=format:%h | grep -E -v '^.{10}$' | perl -pe 's/^(.{10}).*/$1/' You'll get 4 SHA-1s that are ambiguous at 10 characters, this problem will get a lot worse on bigger repositories. Which is not to say that there isn't a lot of room for improvement. The scope creep of initialization time is one of the things that tends to get worse over time without being noticed, but Git unlike (apparently) Python makes huge use of re-invoking itself as part of its own test suite (tens of thousands of times), so it's naturally kept in check somewhat. If you have this use-case I'd encourage you to start a thread on the Git mailing list about it.
marshray 8y ago
Here's what has worked for me: 1. Don't do that. Either write the driving app in Python or write the subprocesses in an ahead-of-time compiled language. Python's a great language but it's not the right tool for everything. 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.
- pfranz 8y ago
  I've definitely seen significant improvements with #2. Unfortunately, it's not very Pythonic to tuck your imports into functions (or under conditionals). It would be nice if imports were more lazily evaluated.
- JoshTriplett 8y ago
  > Don't do that. Either write the driving app in Python Even if you write the driver in Python, you don't necessarily want to call the program you're testing in the same process. You might want independent launches of a command-line tool, so that you test the same behavior people get when they run the tool. Otherwise, your test suite might trip over some internal state that gets preserved from run to run in ways that command-line invocation wouldn't.
  - marshray 8y ago
    Good point, but I didn't mean to sound specific to testing apps. I just meant, in general, write big apps using Python top-down and something precompiled if you must spawn lots of external processes.
strkek 8y ago
IIRC CPython devs reject performance-related patches if they cause the code to become "less readable". >> I believe Mercurial is, finally, slowly porting to Python 3. I just gave up on Mercurial since it didn't let me push to BitBucket nor to an Ubuntu VPS via SSH. For better or worse, Git just works.
- michaelhoffman 8y ago
  I'm confused, since my daily workflow is pushing to Bitbucket via hg and ssh.
  - Noumenon72 8y ago
    My work is considering switching to Git mostly because we think adopting Bitbucket will force us to. Is that not true? I'd love some reasons to stay with hg...
    - sicariusnoctis 8y ago
      Bitbucket was originally for hg though. Why would switching to git be better?
  - strkek 8y ago
    Imagine my confusion back then. I could push fine to BitBucket if I used Python 2 version locally, and same for my VPS if I used the Python 2 version both locally and remotely. But as soon as I touched the Python 3 version of Mercurial the pull/push problems began. I don't recall the exact error and maybe it's fixed now (this happened like 6 months ago), but I don't think I'll give it another try for some time.
rossdavidh 8y ago
I have to say that my first reaction was: "maybe you shouldn't use python for this, then". If you are using a language in a way that it gets worse in subsequent versions, that's a good sign that they're optimizing for something other than what you care about. 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't mean that either one is good at everything, and it's probably the case that both are growing because they don't try to be good at everything. A good toolbox is better than a multi-tool.
- MBCook 8y ago
  The supposed attitude of the python developers about startup time works against the popular niches Python is supposed to be such a great fit for. Little scripts, glue, short run applications. That’s a problem if that’s an area python wants to compete in.
  - carapace 8y ago
    Yep. Tried to use a Raspberry Pi as my main system for a while and one of the pain points was slooooow startup of Python. As a Python fan I was embarrassed.
  - thanatropism 8y ago
    I might be biased because I'm from the hordes that are moving from Stata and Matlab to Python (but then there are the hordes attracted to data analysis now), but that was never really Python's strong suit, nor its target market. I mean, I was always into little scripts, but I used Tcl and then Perl.
    - eesmith 8y ago
      Back in the 1990s, Python was promoted as a web programming language. This was back in the days when everyone used CGIs. Python came with an cgi module, while in Perl you had to download cgi-lib.pl. I even helped maintain a Python web application that was all CGI-based. So I can assure you that at one point Python was trying to be in the "short run applications" space. They may have given up since then, but that's a different issue. As for me, I do write little scripts in Python. I don't like how most of my run time is spent waiting for Python to get ready. What I really don't like is using NumPy. I tend to re-implement features I want rather than reach for NumPy because that 0.2s import time irks me so much. And it's because the NumPy developers want people to do "import numpy; numpy.reach.into.a.deep.package", so they import most of its submodules. They used to also eval() some code at import, causing even more overhead. I don't know if that's gone away.
Murrawhip 8y ago
I'm just curious why more people don't make use of chg to avoid the mercurial startup time. It seemed to solve it for me - are there drawbacks?
- cup-of-tea 8y ago
  Indeed, it seems like a perfectly good solution to me. I guess it's something about purity and not being the perfect solution. Wouldn't it be great if python was as fast as a C program that took many times longer to write? Yes, but that would probably be magic.
- im3w1l 8y ago
  At a guess: They didn't hear about it (keeping your ears open is a cost not everyone wants to pay). They don't want to bother with setting it up. They don't want to bother with maintaining it (even if it's as simple as reinstall every time you get a new computer).
  - Murrawhip 8y ago
    That's fair. My experience with it so far has literally just been aliasing hg to chg. It performed all the magic in the background for me.
- MBCook 8y ago
  Isn’t that really a just a bandaid over the real problem though? The fact the developers of hg went so far as to make that shows startup time is a real issue. So why not fix the problem at the source?
agumonkey 8y ago
I hate to admit it but it's partly why I don't use clojure (pardon the side-topic) more. I can't bear the boot process and the overall cost. Python is free to tinker, and all similar interpreters are joyful to use. Anything else is probably better for heavy duty jobs environments.
- cup-of-tea 8y ago
  It's the main reason I don't use Clojure. I was so excited to learn a modern Lisp. Got an my tools working and wrote my first cli app. Horrendous load time. I realised it's really only suitable for long running processes and I never do that sort of thing so can't use it.
- john2x 8y ago
  I feel the same way about Clojure. For a LISP, where interactive development via the REPL is supposed to be one of the value-add of the language, it falls completely short in that aspect. They even have entire libraries and design patterns (Component, etc.) to work around the issue, but I find it ridiculous that your entire program structure is dictated by the fact that the REPL boot up time is too damn slow.
jahvo 8y ago
Slowness is the elephant in the room in Python land. It's like everybody has decided to cover their eyes in front of this massive pachyderm. A massive delusion
- solarkraft 8y ago
  Delusion? I don't think many cover their eyes. More likely they've come to accept that for their use cases the performance is good enough and the convenience gain well worth it.
zwieback 8y ago
Python is great for prototyping or even real apps if performance isn't so critical. However, more than once I'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. What's even more annoying is that my Python code usually calls a whole lot of C libraries (OpenCV, numpy, etc.) So it's like this: app->OS process->python interpreter->my python code->C libraries. That just really feels wrong so I'd like two things: 1) better/easier path to embed python scripts into my app e.g. resident interpreter 2) some way of passing scripts to python without restarting a new process, this may exist and I'm unaware
adriaferre_ 8y ago
barsa sempre joder
stinos 8y ago
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'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'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/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'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/init code of just something like 100 LOC (including argument parsing etc). Yes I know it'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/or possibly spend time on features which aren't used by many users and/or possibly drags along some old cruft. Not sure, just guessing.
- airstrike 8y ago
  http://boo-lang.org/ http://boo-lang.org/
  - tecleandor 8y ago
    Context?
- deleted 8y ago
  [deleted]
quotemstr 8y ago
I've always been disappointed by how large software projects, both FOSS and commercial, lose their "can do" spirit with age. Long-time contributors become very quick with a "no". They dismiss longstanding problems as illegitimate use cases and reject patches with vague and impervious arguments about "maintainability" or "complexity". 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. You can see this attitude of "no" on this very HN thread. Read the comments! Instead of talking about ways we can make Python startup faster, we're seeing arguments that Python shouldn't be fast, we shouldn't try to make it faster, and that programs (and, by implication, programmers) who want Python startup to be fast are somehow illegitimate. It'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.
- draw_down 8y ago
  For a large enough project or area of concern, saying "no" to many things is essential to saying "yes" to anything.
- gnulinux 8y ago
  I think your comment is well-intentioned (I upvoted) but I respectfully disagree. I think wanting Python to be a bit faster is similar to wanting Haskell to have a little bit of mutability. Engineering with restrictions is a good thing, we can do great systems in Haskell because it's a very neat language even though it lacks mutability. We also can do great systems in Python because it's a very neat language even though it's a bit slow. Sure, you can always optimize Python's performance, that's a legitimate problem and it takes a few engineers to solve it. But it's more interesting to work around Python's slowness by engineering tricks such as better algorithms etc.
  - jsharpe 8y ago
    That's not a great analogy. Haskell is a neat language in part because it doesn't have mutability. Python is a neat language despite being slow. I can't imagine anyone would object if Python could magically be 10x faster. I can't say the same thing for the Haskell thing.
oneweekwonder 8y ago
in the temple of tmux for the cult of vi we sit and wait for venv to activate
bayesian_horse 8y ago
Knock, Knock, who's there? ---- Long Pause --- Java!
avar 8y ago
Best out of 5 times on my Debian testing laptop for a "hello world", in order of worst to best: ruby2.5: 83ms (-e 'puts "hi"') python3.6: 35ms (-c 'print("hi")') python2.7: 24ms (-c 'print("hi")') perl5.26.2: 8ms (-e 'print "hi"') C (GCC 7.3): 2ms (int main(void) { puts("hi"); })
- masklinn 8y ago
  > C (GCC 7.3): 2ms (int main(void) { puts("hi"); }) Not really a fair comparison given the other 3/4 have to do all their parsing and compiling. Unless in those 2ms you include compilation time. Or use tcc -run.
  - avar 8y ago
    The user doesn't care, they just invoke "hg" or "git", and language is always a choice, so it's valid from that perspective. But the reason I included it is because it gives a baseline for the overhead of invoking any program, no matter how trivial.
    - emj 8y ago
      I must say even 2 ms feels rather slow just to execute something hot in cache.
- kzrdude 8y ago
  35ms for Python is ok. What we see in reality is that the imports that a real application will use, adds a whole lot more time. For example, if you want a snappy command line response for a Gtk-using Python program, you probably want to handle command line arguments before even importing Gtk. Maybe it is --help or an argument that you pass on to another running instance, and you want it to be absolutely snappy and fast.
  - solarkraft 8y ago
    I have read that conditional imports are "un-pythonic", but I tend to do exactly that in order to keep resource usage lower.
kelvin0 8y ago
I'm a long time python user, but never really peeked under the hood. However, I have a few ideas. Optimized modules loading: maybe loading a larger 'super' module would be faster than several smaller ones? For example a python program could be analyzed to find it's dependent modules, and then pack all these into a 'super' module. Once the python program executes, it would load the single 'super' module and hopefully bypass all the dynamic code which each module runs when imported to load up. As mentioned previously, this is just off the top of my head and would certainly warrant more investigation/profiling to confirm my hypothesis.
deleted 8y ago
[deleted]
pjc50 8y ago
Proposed solution: steal undump from emacs. https://news.ycombinator.com/item?id=13073566 https://news.ycombinator.com/item?id=13073566 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.
- hobofan 8y ago
  I'm pretty sure Python 3 already does this, and that's what the __pycache__ directories it creates when running a command are for.
  - lmm 8y ago
    Those are only bytecode. It helps a little but you still have to load the file from the filesystem and run it on import.
NelsonMinar 8y ago
I agree Python's startup time is too slow. But one trick you can use to improve it some is the "-S" 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. The drawback is this may screw up your Python environment, not sure how easy it is to work around it if it does.
makecheck 8y ago
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.
bgongfu 8y ago
I'm pretty sure it's too late by now for Python, but I'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. [0] https://github.com/basic-gongfu/cixl#compiling https://github.com/basic-gongfu/cixl#compiling

662 points by vanni 8y ago

It'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've already fucked up.

est 8y ago

Reminds me of buildout. It'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!!!

area_man 8y ago

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: https://github.com/msolo/pyzy https://github.com/msolo/pyzy

beiller 8y ago

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

YesThatTom2 8y ago

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

falcolas 8y ago

Naive question: If the startup time matters because you're imposing that startup time hundreds or thousands of times - why not remove the startup time? I'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. This isn't a new problem, nor is it even a new solution. No complete re-write of the interpreter or the tool required. Anyways, that's my 2¢

price 8y ago
There's a paragraph in the OP about how they've actually done this: > Mercurial provides a `chg` program that essentially spins up a daemon `hg` process running a "command server" so the `chg` program [written in C - no startup overhead] can dispatch commands to an already-running Python/`hg` process and avoid paying the startup overhead cost. When you run Mercurial's test suite using `chg`, it completes minutes faster. `chg` exists mainly as a workaround for slow startup overhead. Just like this isn't what the usual `emacs` command does (it's `emacsclient`), it isn't what the usual `hg` command does either. There are some disadvantages to this solution and some assumptions it makes, which have apparently led the Mercurial maintainers to conclude, like the Emacs maintainers, that it won't work as the default. Hence the desire for solutions that will.

abk786 8y ago

dsaf

SZJX 8y ago

Startup time has also been the biggest gripe I have with Julia so far. Otherwise it's a truly fantastic language to work in. I wasn't able to put the `__precompile__()` function to good use it seems - the time it takes to execute my program didn't change at all for some reason. Or maybe it'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.

ChrisRackauckas 8y ago
precompile doesn't store native compiled code. Though I know from talking to the compiler developers that this is high on the 1.x list. It's an annoyance but at least it has a clear solution in sight.

crb002 8y ago

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

peterkelly 8y ago

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

std_throwaway 8y ago
But what else do you switch to? Imagine you import tons of modules which often are only available in Python. This gets you going really quickly with your project and it runs very smoothly. Transferring this to C++ would probably take so long you won't even finish to find out before you run out of funding. I have hopes that Rust or some descendant of Rust will get us there in maybe 10 years but in the meantime it would be better to get Python up to speed as good as possible.
- julvo 8y ago
  For some use cases, Go might be a good alternative to Python. It's performant, yet simple and readable and it has a great ecosystem.
  - std_throwaway 8y ago
    Do we have numpy, matplotlib, scipy, pickle etc. for Go?
    - jerf 8y ago
      Do the build processes mentioned in this email make heavy use of numpy, matplotlib, scipy, pickle, etc.? NumPy is very exciting and all, but it's a subcommunity of the Python community, not 90% of its usage. NumPy users are probably not, in general, trying to spawn twenty five thousand processes in sequence to accomplish some task. The people who are complaining about fractions of a millisecond of startup time are not inverting massive matrices.
      - std_throwaway 8y ago

std_throwaway 8y ago

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're ready to release. I really wish the creators of Python would have given such use-cases more consideration. Edit: I'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've tested it. It doesn't really pre-compile the modules. The startup time was exactly the same.

alexhutcheson 8y ago
Check out subpar: https://github.com/google/subpar https://github.com/google/subpar
sametmax 8y ago
Nuikta (http://nuitka.net/ http://nuitka.net/) already does that and much more: - it compiles your program and make it stand alone so you can distribute just the exe - it makes it start faster - it makes it run faster - it's fully independant of the system python. Actually your system doesn't even need a python at all I don't get why it's not used, it's very robust, compatible with 3.6 and on some of my script I get about x4 speed up just on start up alone.
- rhizome 8y ago
  Is it a perl2exe descendant, packing the interpreter into an executable wrapper?
  - sametmax 8y ago
    No it compiles python to C, then compile the C.
- std_throwaway 8y ago
  This is different from the package that I've tested (PyInstaller or py2exe). Is Nuikta compatible with numpy, pickle, etc? I remember that numpy was very problematic with compilers like pypy for a long time.

2RTZZSro 8y ago

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?

std_throwaway 8y ago
I imagine this could be handled by some kind of "fork". Where you instantly duplicate the whole process with copy-on-write.
tlrobinson 8y ago
Or just use the operating system's `fork` system call? There's also nailgun for Java which sounds like it works a little differently: http://martiansoftware.com/nailgun/ http://martiansoftware.com/nailgun/
- amelius 8y ago
  I guess a fork()'ed process triggers copy-on-write behavior in the kernel once the process starts running. So that's latency (the copying) you could still optimize away.
  - greglindahl 8y ago
    You might want to measure it before you optimize it! Oftentimes I find that forks where I don't write much are quite inexpensive, with little COW action.
    - amelius 8y ago
      You could be right. Also, could it be that Intel's cache hierarchy plays some really smart tricks behind the scenes, to make this fast?
  - hawski 8y ago
    I may be wrong, but I would bet that copy-on-write of pages would be hardly visible for most workloads. Copying is quite fast when you do it in batches (4k per page).

fpoling 8y ago

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.

feedmeseymour 8y ago
Perl is “just as portable” in the same way that a motorcycle can just as easily drive under a steamroller... it’s not gonna be pretty and there’s no easy way out if you do it.
- ryl00 8y ago
  I write Perl scripts for Windows and Linux, and I don't find portability to be especially onerous. Of course there are platform differences to keep in mind, but is that any different from any other cross-platform scripting language?
jdashg 8y ago
Compile time is absolutely dominated by c++ (and now rust) compilation and linking. I doubt build system language choice will ever bubble up to relevance, so why optimize for it?
ch4s3 8y ago
I imagine there are two aspects to this, they probably started in python and have a lot of it already, and it's probably easier to gen new folks involved which I think is one of their goals.
sametmax 8y ago
I've built firefox from source. Python start up time is not really a problem, it's so long to build anything anyway.
- kevincox 8y ago
  I imagine a lot of the pain is for incremental builds where the build system overheads can matter a lot more.

the_mitsuhiko 8y ago

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. I'm really curious why there hasn't been much of a desire to change this and it even got worse as time progressed which is odd.

stevekemp 8y ago
Indeed this is a long-standing issue with Python. LWN gave some excellent coverage late last year, in this piece: https://lwn.net/Articles/730915/ https://lwn.net/Articles/730915/
fulafel 8y ago
Sure there has been desire to change this. It's a hard problem, and there are tradeoffs.
- the_mitsuhiko 8y ago
  It’s only a hard problem if there is no desire. The slowdowns for the interpreter startup did not happen because they are necessary but because site.py and friends just do more stuff now and a lot of important internal tooling became unnecessarily complex.
  - zbxxx 8y ago
    Yeah, this whole "importlib in Python" thing continues to mystify me.
    - pas 8y ago
      It would be okay, if Python would support a low level faster subPython within itself. RPython for example.
sametmax 8y ago
> it even got worse as time progressed which is odd. Quite the contrary, as I stated in my other comment, we now have nuikta.

deaps 8y ago

I totally understand that milliseconds matter in the use case described in the article. For me, personally, I use python to automate tasks - or to quickly parse through loads and loads of data. To me, startup speed is somewhat irrelevant. 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 'internet' server, available to me (and my coworkers) over port 80 or 443. My internet server, which runs python on the backend (and uses apache to actually serve the GET / POST) literally spits out pages in 0.012 seconds. Some of the 'tools' 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 / internet RTT). To me, that's good enough - adding 30 or even 300 milliseconds to any of that just wouldn't matter. 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'm not concerned with the current startup time one bit.

cjhanks 8y ago
As expected, language start up time only matters to some people. Often in my case, Python is used to build command line tools (similar to the case of Mercurial). In such an event, the start-up time of the program might dominate the total run time of the application. And on my laptop or desktop with a fast SSD with good caching and a reasonably fast CPU... that still ends up being 'okay'. But once I put that on an ARM chip with a mediocre hard drive - some python scripts spend so long initializing that they are practically unusable. Whereas the comparable Perl/BASH script runs almost instantaneously. Often to make Python even practically usable for such systems I have to implement my own lazily loaded module system. Having some language which allowed me to say... import(eager) some_module import(lazy) another_module Which could trigger the import process only when that module becomes necessary (if ever).
- mywittyname 8y ago
  Have you tried moving import statements into the functions where they are invoked? My understanding is this is effectively the same as lazy loading the module[1]. [1] https://stackoverflow.com/questions/3095071/in-python-what-happens-when-you-import-inside-of-a-function https://stackoverflow.com/questions/3095071/in-python-what-h...

faho 8y ago

Mercurial's startup time is the reason why, for fish, I've implemented code to figure out if something might be a hg repo myself. 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. The equivalent `git rev-parse` call takes about 8ms.

anonymouz 8y ago
Somewhat tangentially, I noticed that fish performs quit badly in remote-mounted (sshfs) directories that are git repositories. I wonder if it would be possible to detect a remote mounted filesystem and turn off/tone down some of the round-trip heavy operations?
- justusw 8y ago
  I've gone through your problem myself countless times, and concluded that hitting ctrl+c to interrupt the status line every time it tries to render the current repository state is not very productive. My git status line uses timelimit (https://devel.ringlet.net/sysutils/timelimit/ https://devel.ringlet.net/sysutils/timelimit/) to automatically stop if any of the git status parts (dirty/staged/new files) take > 0.1 seconds to finish: https://github.com/justuswilhelm/pufferfish/blob/master/fish/functions/git_status.fish https://github.com/justuswilhelm/pufferfish/blob/master/fish...
majewsky 8y ago
Wow, that's quite a difference. But 8ms is still too slow for me. :) I implemented the Git recognition code myself in my own prompt using the minimal amount of FS operations [1], and it renders in 5 ms from start to finish, including a "git:branch-name/47d72fe825" display. [1] https://github.com/majewsky/gofu/blob/master/pkg/prompt/git.go https://github.com/majewsky/gofu/blob/master/pkg/prompt/git....
- avar 8y ago
  (I work on Git in my copious free time) One of the reasons git-rev-parse takes slightly longer than your implementation is that you just unconditionally truncate the SHA-1 to 10 bytes. E.g. run this on linux.git: git log --oneline --abbrev=10 --pretty=format:%h | grep -E -v '^.{10}$' | perl -pe 's/^(.{10}).*/$1/' You'll get 4 SHA-1s that are ambiguous at 10 characters, this problem will get a lot worse on bigger repositories. Which is not to say that there isn't a lot of room for improvement. The scope creep of initialization time is one of the things that tends to get worse over time without being noticed, but Git unlike (apparently) Python makes huge use of re-invoking itself as part of its own test suite (tens of thousands of times), so it's naturally kept in check somewhat. If you have this use-case I'd encourage you to start a thread on the Git mailing list about it.

marshray 8y ago

Here's what has worked for me: 1. Don't do that. Either write the driving app in Python or write the subprocesses in an ahead-of-time compiled language. Python's a great language but it's not the right tool for everything. 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.

pfranz 8y ago
I've definitely seen significant improvements with #2. Unfortunately, it's not very Pythonic to tuck your imports into functions (or under conditionals). It would be nice if imports were more lazily evaluated.
JoshTriplett 8y ago
> Don't do that. Either write the driving app in Python Even if you write the driver in Python, you don't necessarily want to call the program you're testing in the same process. You might want independent launches of a command-line tool, so that you test the same behavior people get when they run the tool. Otherwise, your test suite might trip over some internal state that gets preserved from run to run in ways that command-line invocation wouldn't.
- marshray 8y ago
  Good point, but I didn't mean to sound specific to testing apps. I just meant, in general, write big apps using Python top-down and something precompiled if you must spawn lots of external processes.

strkek 8y ago

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

michaelhoffman 8y ago
I'm confused, since my daily workflow is pushing to Bitbucket via hg and ssh.
- Noumenon72 8y ago
  My work is considering switching to Git mostly because we think adopting Bitbucket will force us to. Is that not true? I'd love some reasons to stay with hg...
  - sicariusnoctis 8y ago
    Bitbucket was originally for hg though. Why would switching to git be better?
- strkek 8y ago
  Imagine my confusion back then. I could push fine to BitBucket if I used Python 2 version locally, and same for my VPS if I used the Python 2 version both locally and remotely. But as soon as I touched the Python 3 version of Mercurial the pull/push problems began. I don't recall the exact error and maybe it's fixed now (this happened like 6 months ago), but I don't think I'll give it another try for some time.

rossdavidh 8y ago

I have to say that my first reaction was: "maybe you shouldn't use python for this, then". If you are using a language in a way that it gets worse in subsequent versions, that's a good sign that they're optimizing for something other than what you care about. 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't mean that either one is good at everything, and it's probably the case that both are growing because they don't try to be good at everything. A good toolbox is better than a multi-tool.

MBCook 8y ago
The supposed attitude of the python developers about startup time works against the popular niches Python is supposed to be such a great fit for. Little scripts, glue, short run applications. That’s a problem if that’s an area python wants to compete in.
- carapace 8y ago
  Yep. Tried to use a Raspberry Pi as my main system for a while and one of the pain points was slooooow startup of Python. As a Python fan I was embarrassed.
- thanatropism 8y ago
  I might be biased because I'm from the hordes that are moving from Stata and Matlab to Python (but then there are the hordes attracted to data analysis now), but that was never really Python's strong suit, nor its target market. I mean, I was always into little scripts, but I used Tcl and then Perl.
  - eesmith 8y ago
    Back in the 1990s, Python was promoted as a web programming language. This was back in the days when everyone used CGIs. Python came with an cgi module, while in Perl you had to download cgi-lib.pl. I even helped maintain a Python web application that was all CGI-based. So I can assure you that at one point Python was trying to be in the "short run applications" space. They may have given up since then, but that's a different issue. As for me, I do write little scripts in Python. I don't like how most of my run time is spent waiting for Python to get ready. What I really don't like is using NumPy. I tend to re-implement features I want rather than reach for NumPy because that 0.2s import time irks me so much. And it's because the NumPy developers want people to do "import numpy; numpy.reach.into.a.deep.package", so they import most of its submodules. They used to also eval() some code at import, causing even more overhead. I don't know if that's gone away.

Murrawhip 8y ago

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

cup-of-tea 8y ago
Indeed, it seems like a perfectly good solution to me. I guess it's something about purity and not being the perfect solution. Wouldn't it be great if python was as fast as a C program that took many times longer to write? Yes, but that would probably be magic.
im3w1l 8y ago
At a guess: They didn't hear about it (keeping your ears open is a cost not everyone wants to pay). They don't want to bother with setting it up. They don't want to bother with maintaining it (even if it's as simple as reinstall every time you get a new computer).
- Murrawhip 8y ago
  That's fair. My experience with it so far has literally just been aliasing hg to chg. It performed all the magic in the background for me.
MBCook 8y ago
Isn’t that really a just a bandaid over the real problem though? The fact the developers of hg went so far as to make that shows startup time is a real issue. So why not fix the problem at the source?

agumonkey 8y ago

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

cup-of-tea 8y ago
It's the main reason I don't use Clojure. I was so excited to learn a modern Lisp. Got an my tools working and wrote my first cli app. Horrendous load time. I realised it's really only suitable for long running processes and I never do that sort of thing so can't use it.
john2x 8y ago
I feel the same way about Clojure. For a LISP, where interactive development via the REPL is supposed to be one of the value-add of the language, it falls completely short in that aspect. They even have entire libraries and design patterns (Component, etc.) to work around the issue, but I find it ridiculous that your entire program structure is dictated by the fact that the REPL boot up time is too damn slow.

jahvo 8y ago

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

solarkraft 8y ago
Delusion? I don't think many cover their eyes. More likely they've come to accept that for their use cases the performance is good enough and the convenience gain well worth it.

zwieback 8y ago

Python is great for prototyping or even real apps if performance isn't so critical. However, more than once I'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. What's even more annoying is that my Python code usually calls a whole lot of C libraries (OpenCV, numpy, etc.) So it's like this: app->OS process->python interpreter->my python code->C libraries. That just really feels wrong so I'd like two things: 1) better/easier path to embed python scripts into my app e.g. resident interpreter 2) some way of passing scripts to python without restarting a new process, this may exist and I'm unaware

adriaferre_ 8y ago

barsa sempre joder

stinos 8y ago

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'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'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/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'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/init code of just something like 100 LOC (including argument parsing etc). Yes I know it'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/or possibly spend time on features which aren't used by many users and/or possibly drags along some old cruft. Not sure, just guessing.

airstrike 8y ago
http://boo-lang.org/ http://boo-lang.org/
- tecleandor 8y ago
  Context?
deleted 8y ago
[deleted]

quotemstr 8y ago

I've always been disappointed by how large software projects, both FOSS and commercial, lose their "can do" spirit with age. Long-time contributors become very quick with a "no". They dismiss longstanding problems as illegitimate use cases and reject patches with vague and impervious arguments about "maintainability" or "complexity". 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. You can see this attitude of "no" on this very HN thread. Read the comments! Instead of talking about ways we can make Python startup faster, we're seeing arguments that Python shouldn't be fast, we shouldn't try to make it faster, and that programs (and, by implication, programmers) who want Python startup to be fast are somehow illegitimate. It'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.

draw_down 8y ago
For a large enough project or area of concern, saying "no" to many things is essential to saying "yes" to anything.
gnulinux 8y ago
I think your comment is well-intentioned (I upvoted) but I respectfully disagree. I think wanting Python to be a bit faster is similar to wanting Haskell to have a little bit of mutability. Engineering with restrictions is a good thing, we can do great systems in Haskell because it's a very neat language even though it lacks mutability. We also can do great systems in Python because it's a very neat language even though it's a bit slow. Sure, you can always optimize Python's performance, that's a legitimate problem and it takes a few engineers to solve it. But it's more interesting to work around Python's slowness by engineering tricks such as better algorithms etc.
- jsharpe 8y ago
  That's not a great analogy. Haskell is a neat language in part because it doesn't have mutability. Python is a neat language despite being slow. I can't imagine anyone would object if Python could magically be 10x faster. I can't say the same thing for the Haskell thing.

oneweekwonder 8y ago

in the temple of tmux for the cult of vi we sit and wait for venv to activate

bayesian_horse 8y ago

Knock, Knock, who's there? ---- Long Pause --- Java!

avar 8y ago

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

masklinn 8y ago
> C (GCC 7.3): 2ms (int main(void) { puts("hi"); }) Not really a fair comparison given the other 3/4 have to do all their parsing and compiling. Unless in those 2ms you include compilation time. Or use tcc -run.
- avar 8y ago
  The user doesn't care, they just invoke "hg" or "git", and language is always a choice, so it's valid from that perspective. But the reason I included it is because it gives a baseline for the overhead of invoking any program, no matter how trivial.
  - emj 8y ago
    I must say even 2 ms feels rather slow just to execute something hot in cache.
kzrdude 8y ago
35ms for Python is ok. What we see in reality is that the imports that a real application will use, adds a whole lot more time. For example, if you want a snappy command line response for a Gtk-using Python program, you probably want to handle command line arguments before even importing Gtk. Maybe it is --help or an argument that you pass on to another running instance, and you want it to be absolutely snappy and fast.
- solarkraft 8y ago
  I have read that conditional imports are "un-pythonic", but I tend to do exactly that in order to keep resource usage lower.

kelvin0 8y ago

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

deleted 8y ago

[deleted]

pjc50 8y ago

Proposed solution: steal undump from emacs. https://news.ycombinator.com/item?id=13073566 https://news.ycombinator.com/item?id=13073566 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.

hobofan 8y ago
I'm pretty sure Python 3 already does this, and that's what the __pycache__ directories it creates when running a command are for.
- lmm 8y ago
  Those are only bytecode. It helps a little but you still have to load the file from the filesystem and run it on import.

NelsonMinar 8y ago

I agree Python's startup time is too slow. But one trick you can use to improve it some is the "-S" 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. The drawback is this may screw up your Python environment, not sure how easy it is to work around it if it does.

makecheck 8y ago

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.

bgongfu 8y ago

I'm pretty sure it's too late by now for Python, but I'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. [0] https://github.com/basic-gongfu/cixl#compiling https://github.com/basic-gongfu/cixl#compiling