Hacker News new | past | comments | ask | show | jobs | submit login

Compared speed to Python 3.9 using python-speed for those who want a simpler, more straight-forward benchmark. [1]

Basically one can expect overall 24% increase in performance "for free" in a typical application.

Improvements across the board in all major categories. Seriously impressive.

Stack usage and multiprocessing had the largest performance increase. Even regex had 21% increase. Just wow!

And this may be the first Python3 that will actually be faster (about 5%) than Python 2.7. We've waited 12 years for this... Excited about Python's future!

-----

python-speed v1.3 using python v3.9.2

string/mem: 2400.67 ms

pi calc/math: 2996.1 ms

regex: 3201.59 ms

fibonnaci/stack: 2487.13 ms

multiprocess: 812.37 ms

total: 11897.85 ms (lower is better)

-----

python-speed v1.3 using python v3.11.0

string/mem: 2234.78 ms

pi calc/math: 2667.84 ms

regex: 2548.81 ms

fibonnaci/stack: 1149.57 ms

multiprocess: 480.25 ms

total: 9081.25 ms (lower is better)

-----

[1] https://github.com/vprelovac/python-speed




Python:

  def f(x):  
    return x * x;  
  v=0.0  
  for i in range(100000000):  
    v = v + f(i)  
Execution time: 15 seconds

---

JavaScript:

  function f(x) { return x * x; } 
  var v = 0.0;  
  for(var i = 0; i < 100000000; i++) v += f(i);  
Execution time: 0.5 seconds

---

So calling a function in a for loop in Python is still 30x slower than in JavaScript which is an as-dynamic language. Good to see a 24% increase, but a 3000% increase should still be possible.

I did this test in python 3.10, not python 3.11, but I assume if they did have a 30x speedup from the inlined python to python function calls this would have been mentioned, but the fastest speedup listed is 1.96x faster.


> JavaScript which is an as-dynamic language

It really is not. Python allows a huge amount of the object model to be overridden and introspected at any point. Javascript doesn't even allow operator overloading.


Can't Python just get a `const` keyword and CPython can then optimize accordingly ?


You that like its a bad thing :-P


True, but if I want a proper type system then JavaScript is not an option either.


Presumably you're comparing a JavaScript JIT to interpreted Python (CPython)?

Surely PyPy would be a fairer comparison


Indeed comparing with CPython, which the link is about.

Indeed CPython is not JIT and PyPy is, but CPython is unfortunately usually what you get, comparing with PyPy would not be fairer since the goal is to speed up "vanilla" CPython.

It's unfortunate to me that the default python interpreter, so widely used for scientific computational purposes, is so much slower than the JS interpreter you get in your web browser, and then we're being happy +24% benchmark results about this when 30x faster is known to be possible (e.g. with JIT).


Just checked and pypy has the same speed as JS (instant). You are right that this is not what the most people use when working with Python and there is package incompatibility.

I am curious but don't have the time to check would the same result be for a regex?


I didn't check myself, but in the link from the other comment regex is the one thing where python wins!

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

Of course this is testing two native implementations of regex parsing, not the higher level scripting language handling.


PCRE2 "wins" ;-)


Right but there's no "standard" JavaScript engine either. Benchmarking V8 against CPython and pointing out a totally expected 30x speed difference isn't insightful


I still have to disagree, it's not because both slow and fast JS engines exist (recent ones vs those from before around 2008), or both slow and fast python engines exist (CPython vs PyPy), that it's not ok to point out that the vanilla official python interpreter is much slower than possible.

Why does one have to be ok with a totally expected speed difference? This is the official interpreter of a language, they give a slow tool by default, the official tool deserves scrutiny.



Just on the python3/python2.7 speed... This one has always killed me on BeagleBones...

`$ time python3 -c "print('hello')"`

I have a handful of utility scripts written in python, and the overhead of starting/stopping is just massive! (Sadly, I don't have one on hand to actually print a metric...)


If your script doesn't need any third-party modules, you can try running it with "python3 -S", which should make the startup significantly faster if there are a lot of modules installed. (Twice as fast on my machine. Running Python from a venv is also somewhat faster than running it directly, but not as fast as with "-S".)


Here you go, on a BeagleBoneBlack:

    $ time python3 -c "print('hello')"
    hello

    real    0m0.223s
    user    0m0.148s
    sys     0m0.047s
and, for the record:

    $ python3 bench.py
    python-speed v1.3 using python v3.7.3
    string/mem: 46673.98 ms
    pi calc/math: 98650.32 ms
    regex: 38489.41 ms
    fibonnaci/stack:  30723.3 ms
    multiprocess: 75500.34 ms

    total:  290037.35 ms (lower is better)
Might get a little better with some tweaking of performance governors / idle states enabled but, yeah...


Luckily in most cases a python web app is 'served' so it does not have this start-up overhead.


Just because 10000 companies are making some random webapps in python doesn't make the 10 local Python apps any less bothersome. This is literally what killed java for end-users.


Interestingly, Java has been improving lately in this regard, thanks to cloud and container use-cases. There was a big regression with Java 9, but since then it's been getting better with each release.

Numbers for "hello world" on my machine:

Java 7: 43 ms

Java 8: 29 ms

Java 11: 34 ms

Java 18: 22 ms

Python 2.7: 6 ms

Python 3.10: 12 ms

Perl 5: 1 ms




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: