Python 3.11 Performance Benchmarks Are Looking Fantastic

[ddriver]

Yeah, bread is very popular too. Still - terrible nutritional value. Many people can live on that tho, most due to lack of choice for anything better. Amazing what odd things people can grow accustomed to.

[rclark]

The problem is that it will never be fast enough.

It is fast enough for 'a lot' of tasks in our company. It is a super language that even engineers can use too and modify when needed. Solves problems easily. One of the big strengths for us is that the source code is the run time code. So when we need to update it for say an IP address or a little bit of logic, all we have to do is change the code 'on the fly' . Next time it runs, the change is accepted. No compiler need apply. Now for our Energy Management System, C/C++ is the go to language as speed is a priority there. That said, Python has made it to just about every corner of our company and none that I know of our complaining about it either like some above . It's a very good language for 'Automating the Boring Stuff' (actually a book title quote) .

Personally I've never had a problem with typing Python syntax either, ... but then I've taken a typing class . Ha!

Of course if you don't like it, you can always go back to Visual Basic, or Lisp, Cobol, or whatever you think 'is the' language is best in your own mind.

[anarki2]

When such huge "optimizations" take place I always wonder how sh*tty the code must've been before.

[darkbasic]

I hope python 3.11 speeds up 'emerge' command on gentoo

That would require a 3000x speedup, not a "mere" 60% performance increase

[bug77]

i agree, the problem here is that it is abused. It is supposed to be used for scripts, it is not used for performance critical applications as well (portage is an example for that).

I can agree with that, but then again, which language isn't? Java/.Net in the cloud? JavaScript on the server?

Not quite. I suggest that people should avoid interpreted languages if performance might be an issue. But since effort on writing software is limited, it would be more beneficial to spend this effort on rewriting applications and libraries (and their APIs) in compiled languages than optimising interpreters.

People are free to do what they wish with their time. And I'll always welcome performance improvements (and code cleanups).
I actually think developing everything in Python first is a good idea. Specs will never be clear enough to identify performance hotspots from the beginning and Python at least gives you a short time-to-market. Once you know your performance hotspots, by all means, rewrite those in Go/Rust/C as needed. I am still on the fence about writing everything in Go first, instead of Python; I think you'd get the same speed of development, but idk if the ecosystems as a whole can compare yet.

[JackLilhammers]

Your post seems to be about stuff other people write and who you don't like than actual issues. At least he is being informative, while you are just being a narcissist.

+1 uid313

...
Here comes the informative version

• PSFL is a permissive license approved by the FSF and the OSI. It's fine
• It'a limitation of CPython, not of the language per se. PyPy can be sandboxed. PS: https://wiki.python.org/moin/SandboxedPython
• ...
• Maybe?
• Not an issue
• A matter of taste. I'm quite comfortable with Python's typing. MyPy works pretty well
• Lambdas in Python are very restricted. Defining named functions is preferred. The syntax is a bit cumbersome, but nothing terrible
• This is legit. There is Sphinx, but it's not standard
• Not an issue
• Other people see value in the match statement, which btw doesn't rely on type hints
• True, but not a big deal

Happy now?

[sinepgib]

Besides changes affecting the Python language itself, Python 3.11 has been landing performance work from the "Faster Cython Project" to speed-up the reference implementation. Python 3.11 is 10~60% faster than Python 3.10 according to the official figures and a 1.22x speed-up with their standard benchmark suite.

It's "Faster CPython Project". Cython is a different beast (it's a superset of Python that can be built into C to create native extensions for CPython).

[st3f4n2006]

That's great..i barely wait to test it when stable.
For those complaining that the performance is bad, go use other languange. The flexibility and ease of use is Python strong suit.
The things Python allows are far more worth than the performance issues. Also Python allow C code to be integrated (i don't know if it's possible,but it will be nice to add rust and other compiled languages).
The good thing for Python is that the pure python libraries rarely required modification to work on the next version (beside 2to3 ). The external code almost always needs update/recompile. So a performance improvement on pure python is always welcomed.

[st3f4n2006]

[*]It has the "walrus operator" which nobody outside of the Python community knows, and since the language targets non-developers it's even more confusing when they muddy the syntax with unnecessary things people don't understand, need or care about.[*]To me it feels like the Python developers added the match statement just because they saw it was popular in other languages. I absolutely love the match statement in Rust and consider it a killer feature, but I don't see any value for it in Python due to it's loosely typed nature and poor support for type hinting.[*]You cannot use this language on Android or iOS.[/LIST]

The "walrus operator" is just a gimmick ..it's good for clearer code (instead of 2 lines you write only one)
Match (or C switch) was needed not for performance but for clarity of code. How it looks in C using a big if vs switch. Also it doesn't have the limitation of C switch on using only integers. The flexibility of match matches the Python Zen https://peps.python.org/pep-0020/
You can use it in Android (maybe not on base level) but you can program and run python scripts (look into the store).

[sinepgib]

I am still on the fence about writing everything in Go first, instead of Python; I think you'd get the same speed of development, but idk if the ecosystems as a whole can compare yet.

Been there, done that. While writing in Go first is absolutely wiser than going for C first, it's hardly an ergonomic language for a prototype. I'd say Python is a good candidate for first implementations, but Go is usually a reasonable one for an end product if you wish to rewrite in something more efficient without excessive effort. Tho, if you can, maybe Cython allows for a more gradual rewrite to native code without ditching all of the existing code, while giving you the ergonomics of Python in lots of places. The problem with that would be that the level of maintainance is not comparable to that of CPython and Go, so if you have the bad luck to bump on a bug it may take a while to get fixed.

Fun fact, in the project I was where they went for Go by default, after I left they ended up rewriting in Python.

i agree, the problem here is that it is abused. It is supposed to be used for scripts, it is not used for performance critical applications as well (portage is an example for that).

And there's nothing wrong with having your scripts run slightly faster. Besides, there is one other thing scripting languages are good at, and that is glue code. For data science, say what you must, but Python strikes a sweet spot: data scientists often come from a math background rather than an engineering one, so having a language where it's harder to make a mess and easier to simply test ideas quickly is a plus, while the actual performance critical stuff is written in a compiled language but exposed transparently as a module for Python.

Now, I agree things like portage shouldn't be scripted. But that's what you get for being an old school unixy fan, Perl, shell scripts, and more recently Python, running for your core services. It's not Python's fault that graybeards are stupid.