Is Python That Slow?

I'm curious if there's more to nodejs's relatively high performance than just Google's time/money put into v8.

Would an equivalent amount of effort on Python have ended in similar performance? Or do python things like "everything's an object", etc, set a hard ceiling?

interestingly, my takeaway from this article is that Nodejs isn't actually as slow as I thought. I thought Rust would be at least two orders of magnitude faster. It's barely just one, for the OPs benchmark.

how can it be possible that nodejs is so fast, or that rust isn't multiple orders of magnitude faster (again, for the OPs benchmark it's about 8-10x faster in one case, and only twice as faster in another, which is much faster, but I expected it to be more like 100x faster).

is v8 really that fast? I'd be curious to see a multi threaded version of this implemented (some arbitrary multi-threaded benchmark). there I would hope that rust is multiple orders of magnitude faster, given that node is single threaded (with some caveats, of course as anyone who knows node knows). surely the rust written wasn't written optimally.

given how easy it is to write typescript compared to Rust and Python imho, maybe the JS community isn't as crazy as I thought

I wish people who aren't in the business of testing had a bit more awareness of the unknown (to them) unknowns...

The article takes a tiny slice of Python: two exceptionally simplistic algorithms that aren't representative of any sort of real-world workload an actual Python program might be tasked with, and then adds a bunch of unknowns s.a. how long does it take the system to load the text of the program, anything about the load of the system running the test etc.

I feel like this is another one of those "politically" motivated articles (i.e. the author likes Python and wants to say something nice about it, regardless of the actual state of events in Python). But then also tries to serve this opinion as "well, this is my take, yours could be different, nobody knows who's right, but nobody else rose to the task of figuring it out, so you might as well go with what I say", as in:

> In the title of this article I asked if Python is really that slow. There isn't an objective answer to this question, so you will need to extract your own conclusions based on the data I presented here, or if interested, run your own benchmarks and complement my results with your own.

Well, no, there is an objective way, but it's hard! It's a lot of work to figure out what's the minimum required time is for the task, or the minimum space etc. and then see if your program, that was proved to be optimal for the task in the given language approaches that limit, and what are the contributing circumstances.

I'd recommend checking out numba (https://pypi.org/project/numba/) - where relevant, it can give huge speedups for minimal effort.

Just adding @numba.njit above the factorial function gives me a 36X speedup, putting it ahead of PyPy/Node.js and just a couple of times slower than Rust.

I use python because I have to, but not because I want to. I have to think twice about using something as basic as a loop, whereas in another language I don't have to.

> ... run your own benchmarks and complement my results with your own.

Of course, people already had.

Of course, NIH, so instead of references to those more comprehensive benchmarks it's recursive fib again.

https://pybenchmarks.org/

https://speed.pypy.org/

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

PyPy looks interesting and it leaves me with a bunch of questions:

Is PyPy used a lot? Why don't we hear more about it? Does it support the same large ecosystem of packages? And does it have a GIL?

When I first started programming, this would have been about 2009.

Everyone said python was slow, learn C++. So i did. I never taught myself python until much later. Huge regrets. All of my open source projects are now in python.

I've discovered there's literally only 1 thing in python that causes it to be slow.

Global Interpreter Lock.

Use multiprocessing and avoid this problem? Now python is as fast as I ever need it to be.

At my work, we realized that Cython is faster so we completely switched to it for our in house testing framework. Given the amount of times we run it, the switch helped a lot. We also have a custom messaging framework that is sensitive to time delays which the non-Cython was affecting our results.

That’s as much as I can say as an anecdote.

Edit: Cython not CPython

Most interesting to me is that PyPy (and Node for that matter) gets the same order of magnitude improvement that Rust does.

Irrelevant.

If you're doing anything even mildly related to ML/stat, Python is essential. It's close to impossible to replicate the eco-system that has been built out in the past 10 years (the Torch people were still in Lua back then).

I only recently started to wet my feet with Python (Micropython, actually) because I wanted to quickly prototype something on small ESP* uControllers, and speed aside I liked it, but what got me angry was its dependence on tabs, I simply will never adapt to that. I certainly lack the expertise to know what went wrong, but wasting a whole half hour to debug a ~25 lines piece of code that had no bugs and no visible errors or alignment problems, then started to work just by loading on a different editor then saving it back without changing a single char, was enough. I'll keep using it because there are not many alternatives among higher level than C languages, but as soon as something else will appear I'll be more than happy to jump ship. Are brackets, parentheses or "end" statements that bad?

> This weekend I was supposed to attend PyCon Ireland, but a nasty cold is forcing me to stay home instead. Without a lot of energy to do much else

It's amazing what he can do when not operating at full strength.

These bar graphs really need to use a logarithmic scale. Also, 0.06s is too small a runtime to measure reliably with an external wrapper, the workload needs to be larger or repeated to get good data.

> In the title of this article I asked if Python is really that slow. There isn't an objective answer to this question, so you will need to extract your own conclusions based on the data I presented here, or if interested, run your own benchmarks and complement my results with your own.

Huh? I mean, author's own benchmarks prove that Python is, indeed, that slow. Not everyone is going to be running their python code through PyPy. There are areas in which Python is invaluable and irreplaceable, but, let's accept things for what they are - it's slow. It only keeps up through libraries that leverages C code, and for those things - it is very acceptable.

The TL;DR is "Yes, Python is slow but this is why is doesn't matter, in these scenarios where it being fast doesn't matter".

And:

"Python is by far the fastest to write, cleanest, more maintainable programming language I know ... I rarely feel Python slows me down, and on the other side I constantly marvel at how fast I code with it compared to other languages."

In other words, "I don't know much about anything else other than Python."

What a pointless article.

First, let me say I am totally in favour of the sentiment here:

Python is by far the fastest to write, cleanest, more maintainable programming language I know, and that a bit of a runtime performance penalty is a small price to pay when I'm rewarded with significant productivity gains. I rarely feel Python slows me down, and on the other side I constantly marvel at how fast I code with it compared to other languages.

Personally I prefer Raku [https://raku.org] to do the same.

Here is the Python code from the article:

  import sys

  def fibo(n):
    if n <= 1:
        return n
    else:
        return fibo(n-1) + fibo(n-2)

  if __name__ == '__main__':
    for n in sys.argv[1:]:
        print(n, fibo(int(n)))

And here is my Raku code:

  sub MAIN(*@n) {
    say (0, 1, *+* ... *)[@n]
  }

So, even better on the "quick to code and easy to maintain" imo.

The performance comparison is interesting too...

CPython 9.72 - 22.10 secs

PyPy 1.65 secs

Node 1.76 secs

Rust 0.25 secs

Raku 0.12 secs

  > time ./fibo.raku 10 20 30 40
  (55 6765 832040 102334155)
  ./fibo.raku 10 20 30 40  0.12s user 0.02s system 114% cpu 0.124 total

Haha (admittedly I am on an M1 not an i5 so this is a bit Apples vs. Oranges ... but CPUs getting faster all the time and Raku has no GIL)

> Python is by far the fastest to write, cleanest, more maintainable programming language I know, and that a bit of a runtime performance penalty is a small price to pay when I'm rewarded with significant productivity gains.

> (…)

> Before you ask, no, I did not include Ruby, PHP or any other of the "slow" languages in this benchmark, simply because I don't currently use any of these languages and I wouldn't start using them even if they showed great results on a benchmark.

Why bother with benchmarks, then? Clearly you don’t care for them and just want to continue using Python because that’s what you’re familiar with and like. That’s fine, it’s your prerogative, you don’t have to justify that choice to anyone who doesn’t have the same priorities you do.

Personally I dislike Python and find it to be far from “the fastest to write, cleanest, more maintainable programming language” and I wouldn’t want to use it even if its performance were amazing. But that doesn’t matter, if we all liked the same things we wouldn’t have so many programming languages. Or operating systems. Or brands of sneakers. Or…

When I run benchmarks, I do so in real use cases, to test different algorithms for a task that will be in production.

yup

Python takes ~180 assembly instructions to add two numbers, where „compiled to machine code“ languages only take one.

Casey Muratori has a real in-depth course on why Python is slow and how to make it fast, among many other things why software can be slow.

https://www.computerenhance.com/