Comment by peterkelly

Performance and startup performance are really seperate things.

For instance, for many many CLI tasks a python script will be many times faster than a Java tool, just due to the JVM startup. It doesn't really matter if the Java would even run INSTANTLY... the JVM startup time just kills speed for small CLI invocations.

Shell is an interpreted language and its startup time is quite fast (5-7 ms on my machine, which is not a particularly fast machine).

In fact, large parts of git were written in shell until they realized that shell is only fast on UNIX because of co-evolution (you can fork without exec, and fork is quite fast), and on other platforms like Windows, existing shell implementations are much slower and there isn't a well-tuned production-ready shell that does things completely differently. Then they started rewriting everything in C.

performance != startup time for lots of applications.

I use a C curses application (dokia) to store some oft-used commands, but anything that won't be run 500x/day or runs longer than ~1/10th of a second I'll write in python for easier/more powerful development

Most of this email thread is comparing Mercurial (Python) to Git. I'm not familiar enough with Git's internals to know why and where the languages are split, but it uses a significant amount of Shell scripting and Perl it its code base. You can put 'git-foo' anywhere on PATH and it'll get picked up. So in the comparison they're making startup time doesn't seem to be an issue for a combination of those languages, but it is for Python. It doesn't sound like their problem is that Python is an interpreted language.

Why shouldn't the interpreted program start faster? Bytecode is usually at least 2x denser than machine code, so all things being equal, when starting an interpreted program, you should be doing less IO, take fewer page faults, and so run faster, at least if you defer computationally-intensive work to specialized AOT-compiled helpers.

That interpreted programs frequently start slower than their compiled equivalents reflects badly on interpreter implementations, not the concept of interpretation itself.

"There are many great reasons to use Python, but execution speed is not one of them."

Um, I think there are lots of examples where using pythons internal data structures as they were designed results in code that is fast enough.

Even though the language implementation is interpreted, lots of common things can be optimized under the hood using data structure and data type specific execution paths and so on.

Maybe you didn't read the post, but in the use cases specified, performance is not important--the author is mostly speaking about deploy and test scripts. Whether these take 1 minute or 10 is not particularly interesting, but you would of course prefer faster if possible. That's the point here--of course a faster Python interpreter is better, and the Python maintainers should place a higher priority on it than the very low priority that they currently do.

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.