python is a language explicitly designed to resist any form of proper optimization. It just can't be made fast
this post was submitted on 10 Jul 2025
75 points (100.0% liked)
Python
7282 readers
2 users here now
Welcome to the Python community on the programming.dev Lemmy instance!
π Events
Past
November 2023
- PyCon Ireland 2023, 11-12th
- PyData Tel Aviv 2023 14th
October 2023
- PyConES Canarias 2023, 6-8th
- DjangoCon US 2023, 16-20th (!django π¬)
July 2023
- PyDelhi Meetup, 2nd
- PyCon Israel, 4-5th
- DFW Pythoneers, 6th
- Django Girls Abraka, 6-7th
- SciPy 2023 10-16th, Austin
- IndyPy, 11th
- Leipzig Python User Group, 11th
- Austin Python, 12th
- EuroPython 2023, 17-23rd
- Austin Python: Evening of Coding, 18th
- PyHEP.dev 2023 - "Python in HEP" Developer's Workshop, 25th
August 2023
- PyLadies Dublin, 15th
- EuroSciPy 2023, 14-18th
September 2023
- PyData Amsterdam, 14-16th
- PyCon UK, 22nd - 25th
π Python project:
- Python
- Documentation
- News & Blog
- Python Planet blog aggregator
π Python Community:
- #python IRC for general questions
- #python-dev IRC for CPython developers
- PySlackers Slack channel
- Python Discord server
- Python Weekly newsletters
- Mailing lists
- Forum
β¨ Python Ecosystem:
π Fediverse
Communities
- #python on Mastodon
- c/django on programming.dev
- c/pythorhead on lemmy.dbzer0.com
Projects
- PythΓΆrhead: a Python library for interacting with Lemmy
- Plemmy: a Python package for accessing the Lemmy API
- pylemmy pylemmy enables simple access to Lemmy's API with Python
- mastodon.py, a Python wrapper for the Mastodon API
Feeds
founded 2 years ago
MODERATORS
it doubled in speed from 3.9 to now, so it's getting there.
That ignores just how slow it is. It's on the order of 100x slower than "fast" languages like Rust and Go, so doubling in speed... while nice for Python Devs doesn't really make it fast on an absolute scale. They need to double it's speed a few more times at least.
go is also not a fast language. it's about halfway between python and c.
but they all solve different problems so that's ok.
Absolute rubbish. Go is typically something like 2-3x slower than "native" languages like C and Rust. Python is typically 50-100x times slower. Go is much much closed to C than it is to Python.
not exactly: https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html tl;dr it can be true, but not necessarily. fast python code is on the magnitude of 1/5th the speed of go.
the thing with python is that there is a huge difference between fast and slow code. in go, only really slow code is slow, and in rust even slow code is fast.
You shouldn't blindly trust those numbers. If you actually read the Python code a lot of them use ctypes to just delegate the work to C. It even says that at the bottom of the page.
Seems like they've finally started calling these out - search for "contentious" on this page:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python3-go.html
i mean, that's what you're supposed to do. python is a glue language, after all.
Nonsense. You are only "supposed" to do that because if you are using Python and you want performance you have no other choice!
Reminds me of people saying you aren't "supposed" to store binaries in git - yeah only because git is so bad at it! When we were all using SVN people would have said "you aren't supposed to have multiple people editing the same file simultaneously" as if it were a fundamental truth.
And Python isn't "a glue language". It's often used like that but there are many many pure Python projects.
but like, most of the standard library is written in c. most popular libraries are written in c. they're built that way because python is a flexible way to glue functionality together. that's the point of python: it's easy. if i want performance, i port part of the logic to a compiled language. but most of the time that's not necessary.
just like how with git, we have lfs. we build what we need when we need it. i don't understand your tone here.
theyβre built that way because python is a flexible way to glue functionality together
Lol no. They're built that way because it's fast! Can you imagine how slow Python would be if it was self hosted? Actually I bet someone has tried that...
Yep - go and benchmark that and get back to me in a few days when it's finished running hello world, lol.
just like how with git, we have lfs
Have you ever actually used LFS? It's a pretty terrible experience.
why are you so combative?
It's frustrating when people make excuses for problems - even saying that there isn't a problem. Like, if everyone was saying "I like Python even though it is extraordinarily slow and will never be fast, which is a shame"... That's fine. Saying "Python isn't supposed to be fast and you shouldn't want that" is delusional.
It's not just Python where this phenomenon happens - I gave the example of Git ("you shouldn't want to version control binaries so the fact that Git sucks at it isn't really a problem at all!"). Another common one is distributing binaries on Linux - you shouldn't want to do that so it doesn't matter that it's a pain in the bum.
Pet peeve I guess.
when the hell did i say python is supposed to be slow? i just said it's supposed to be used as a high-level glue to hold low-level things together. different tools have different uses. you're complaining that a saw is a bad hammer.
i just said itβs supposed to be used as a high-level glue to hold low-level things together.
Exactly. You essentially said it's ok for Python to be slow because it's supposed to only be used to tie together things written in fast languages. That's utter bullshit. It was never designed with that intent, it's just that it turns out people do use it like that because it's so slow.
"essentially". fuck off. i started this entire chain saying that it's good that python is getting faster, and you shut that down too. you're obviously only here to start fights. i'm not interested in continuing this.
Nonsense. You are only "supposed" to do that because if you are using Python and you want performance you have no other choice!
Reminds me of people saying you aren't "supposed" to store binaries in git - yeah only because git is so bad at it! When we were all using SVN people would have said "you aren't supposed to have multiple people editing the same file simultaneously" as if it were a fundamental truth.
And Python isn't "a glue language". It's often used like that but there are many many pure Python projects.
This is a common misconception! It is true that, of the Smalltalk descendants, Python was not designed for speed like Self or Java; but it was not designed to be slow or difficult to compile. The main technique required to implement a Python JIT is virtualizable objects, which allows the JIT to temporarily desynchronize the contents of registers from the contents of the heap; it's not obvious and wasn't in the first few iterations of PyPy. Additionally, it turns out that tracing the meta-level (see docs or the paper) is a key trick: instead of JIT'ing the Python program, the JIT operates on the interpreter, on the Python VM itself!
Please don't show a close-up image of a snake, or at least add a spoiler! It's irrelevant to the topic, and it just sets some of us on edge for no good reason. If it's small, it's fine, but this... holy shit, now I have a headache. It's one of the reasons I stopped coding in Python altogether.
Snake, a snake
Oh, it's a snake
Severus Snake. Dumbledore!
Ah sorry, wrong sketch.
But looms at his little puppy dog face. :3
lol I get it, but it's involuntary. I really wish I could like snakes but I don't think it's happening anytime soon.
This is not entirely fair because the comparison point has changed. CPython is getting much faster, too, thanks to the optimizations stages before the JIT runs.
Python typing system is the reason of its huge flexibility, but as many other scripting language, itβs also what makes it so hard to optimize.
I have no idea how you can change that without bringing some βJIT-orientedβ features inside the Python language itself.
I still hope for the best, but Iβm unsure we will be able to see an efficient JIT system inside CPython soon.
PyPy had to rewrite the whole Python implementation in a JIT focused way, and even with that, they are (not uncommon) cases when PyPy is slower.
I gather that you don't actually use PyPy much. On average, I expect PyPy to deliver over a 3x speedup. The main issue is that people have built upon slow libraries like Numpy that only seem fast because CPython is even slower.
The reason that CPython cannot have a JIT added on is architectural and political. The CPython core team refuses to learn lessons from PyPy.
I'm a fan of type infrence languages
i'm a fan of ladies with complete test coverage
but i'm ok with those who are a fan of type inference.
More ladies for me
Microsoft cancelled its support for the Faster CPython project in May this year, as part of a round of layoffs
wtf did they actually axe Guido? I thought he was heavily involved in that.
His website still says he works for Microsoft, though it's possible he hasn't updated it yet.