Иногда оптимизация в Python напоминает гадание на кофейной гуще: «это медленно, потому что я так чувствую», «async же быстрее, да?», «list вроде норм, зачем set». Исследование, опубликованное Майкл Кеннеди, делает редкую и очень полезную вещь — заменяет ощущения цифрами.
Это не синтетические микро-тесты ради галочек, а сотни реальных замеров на современном CPython 3.14.2. И они внезапно меняют взгляд на то, где Python действительно тормозит, а где — нет.
Оптимизация без фанатизма
Главная ценность работы Кеннеди — не в таблицах (хотя они впечатляют), а в том, что она снимает иллюзии.
- 🧠 многие операции, которые принято «оптимизировать заранее», уже укладываются в десятки наносекунд
- 🐢 а вот некоторые привычные конструкции внезапно оказываются на порядки медленнее, чем кажется
Это даёт редкую роскошь: оптимизировать осознанно, а не на автомате.
Самый показательный пример — структуры данных
Если вынести из всей статьи один вывод, он будет таким:
- 🚀 item in set и item in dict — молниеносные
- 🐌 item in list — катастрофа уже на тысяче элементов
Разница — сотни раз, и это не теория алгоритмов, а реальная практика. После этих цифр аргумент «у меня тут всего список» звучит как технический долг в зародыше.
Память: Python щедр, но не бесплатен
Python удобен, потому что абстрагирует детали. Но абстракции стоят памяти — и немало.
- 📦 пустой dict тяжелее пустого list
- 🧱 __slots__ уменьшают объекты более чем в два раза
- 🧮 даже маленькое число — это полноценный объект
Особенно это бьёт по сервисам с кэшами, очередями и долгоживущими объектами. В таких местах @dataclass(slots=True) — это не «оптимизация», а архитектурное решение.
JSON: стандарт — не значит оптимум
Отдельный сюрприз — сериализация:
- ⚡ orjson и msgspec кратно быстрее стандартного json
- 📉 разница заметна не в микробенчмарках, а в реальных API
- 🧩 Pydantic остаётся удобным, но имеет измеримую цену
Это хороший пример «честной оптимизации»: не переписывать код на C++, а подменить библиотеку.
Async — не ускоритель, а инструмент
Очень полезный холодный душ для любителей async:
- 🕸️ создание и запуск корутин — десятки микросекунд
- ⏱️ синхронный вызов — наносекунды
- ⚠️ async оправдан только при ожидании I/O
Использовать async «на всякий случай» — это как ставить турбину на велосипед.
Мой главный вывод
Это исследование — не про «как выжать максимум». Оно про инженерную трезвость.
- 🔍 сначала — выбрать правильную структуру данных
- 📐 затем — понять стоимость абстракций
- 🛠️ и только потом — оптимизировать горячие места
Python остаётся медленнее C или Rust, но цифры показывают: он гораздо быстрее, чем принято думать, если использовать его осознанно.
Почему такие статьи особенно важны сейчас
Когда Python всё чаще используется:
- 🧠 в ML и data-пайплайнах
- 🌐 в высоконагруженных API
- 🧪 в инфраструктурных сервисах
— знание реальной стоимости операций перестаёт быть академическим. Это уже вопрос архитектуры и денег.
🔗 Ссылки
- Оригинальная статья:
https://mkennedy.codes/posts/python-numbers-every-programmer-should-know/ - Репозиторий с бенчмарками:
https://github.com/mikeckennedy/python-numbers-everyone-should-know
Если коротко: эти цифры — лучший антидот против преждевременной оптимизации и мифов о Python.