[Перевод] Мифы и легенды о производительности Python

Антонио Куни — инженер, давно занимающийся повышением производительности Python, а также разработчик PyPy . Он провёл на EuroPython 2025 в Праге презентацию «Мифы и легенды о производительности Python». Как можно догадаться из названия, он считает многие общепринятые сведения о производительности Python как минимум вводящими в заблуждение. На множестве примеров он показал, где, по его мнению, таятся истинные проблемы. Инженер пришёл к выводу, что управление памятью в конечном итоге наложит ограничения на возможности повышения производительности Python, но у него есть проект SPy , который, возможно, станет способом реализации сверхбыстрого Python. Он начал своё выступление с просьбы: «Если вы считаете Python медленным или недостаточно быстрым, поднимите руку»; поднялось много рук, в отличие от презентации на PyCon Italy, где руку не поднял почти никто из присутствующих. «Совершенно другая аудитория», — сказал он с улыбкой. Антонио уже много лет работает над производительностью Python, он общался с множеством разработчиков на Python и слышал кучу устоявшихся мифов, которые захотел развеять.

https://habr.com/ru/companies/ruvds/articles/935046/

#интерпретатор #оптимизация_кода #jitкомпилятор #ruvds_перевод

[Перевод] Мифы и легенды о производительности Python

Антонио Куни — инженер, давно занимающийся повышением производительности Python, а также разработчик PyPy . Он провёл на EuroPython 2025 в Праге презентацию «Мифы и легенды о производительности Python». Как можно догадаться из названия, он считает многие общепринятые сведения о производительности Python как минимум вводящими в заблуждение. На множестве примеров он показал, где, по его мнению, таятся истинные проблемы. Инженер пришёл к выводу, что управление памятью в конечном итоге наложит ограничения на возможности повышения производительности Python, но у него есть проект SPy , который, возможно, станет способом реализации сверхбыстрого Python. Он начал своё выступление с просьбы: «Если вы считаете Python медленным или недостаточно быстрым, поднимите руку»; поднялось много рук, в отличие от презентации на PyCon Italy, где руку не поднял почти никто из присутствующих. «Совершенно другая аудитория», — сказал он с улыбкой. Антонио уже много лет работает над производительностью Python, он общался с множеством разработчиков на Python и слышал кучу устоявшихся мифов, которые захотел развеять.

https://habr.com/ru/companies/ruvds/articles/935046/

#интерпретатор #оптимизация_кода #jitкомпилятор #ruvds_перевод

Vue: Composables и TS это вам не Mixins и JS. С ними сложнее

Пришел к хитрому паттерну. Делюсь. Будет полезен тем кому нравиться или приходится работать с Vue. В подходящей ситуации он сэкономит кучу времени и поможет избежать дублирования кода. Поехали!

https://habr.com/ru/articles/927214/

#mixins #composables #vue #javascript #typescript #ts #js #props #events #оптимизация_кода

Оптимизация языковой модели Mamba для выполнения на CPU

Как оптимизировать модель Mamba для выполнения на CPU? Ускоряем код в 20 раз по сравнению с PyTorch, нарушая в процессе все правила оптимизации.

https://habr.com/ru/articles/925460/

#mamba #simd #векторизация #оптимизация_кода

FastCGo: как мы ускорили вызов C-кода в Go в 16,5 раза

В Deckhouse Prom++ мы переписали ядро хранения и обработки горячих данных на C++, при этом вся оркестрация и периферия остались в Prometheus на Go, что позволило сохранить полную совместимость с Prometheus. Для частых вызовов кода C++ мы использовали механизм CGo, однако первые тесты показали, что производительность CPU практически не улучшилась из-за его медлительности. В итоге мы переписали CGo, создав собственный механизм вызова. В статье разберём, что такое CGo и почему он такой медленный, сделаем простейший собственный механизм CGo-вызова и доведём этот механизм до полноценного решения.

https://habr.com/ru/companies/flant/articles/923912/

#prom++ #fastcgo #cgo #оптимизация_производительности #go #c++ #оптимизация_кода #разработка_по #prometheus #deckhouse

Статус: в неточном поиске (fuzzy match)

Задача нахождения неточных дубликатов текстовых строк - удивительно часто встречается на практике. Нахождение неточных дубликатов позволяет лучше понять структуру списка, повысить его качество (удаление дубликатов), провести техническую кластеризацию (выделить группы похожих). Всё это видно на графе выше. Но приключения начинаются, когда список становится размером несколько миллионов строк. В статье разберем что с этим можно сделать.

https://habr.com/ru/articles/923080/

#неточный_поиск #fuzzy_matching #похожие_строки #оптимизация_кода #python #неточные_дубликаты #неточное_сопоставление

[Перевод] PostgreSQL Mistakes and How to Avoid Them: Неправильное использование типов данных

Недавно вышла отличная книга PostgreSQL Mistakes and How to Avoid Them от Jimmy Angelakos — системного архитектора, практика и давнего участника сообщества PostgreSQL. Книга подробно разбирает распространённые ошибки, с которыми сталкиваются разработчики и администраторы при работе с PostgreSQL, и предлагает практичные решения: от тонкостей конфигурации и миграции до антипаттернов в SQL и выбора типов данных. Я перевёл одну из ключевых глав этой книги — про неправильное использование типов данных. В ней подробно объясняется, почему, например: timestamp without time zone может ломать логику расчёта интервалов; money — это не то, чем кажется (и почему он опасен); char(n) и varchar(n) не дают ожидаемой экономии и даже вредны; serial — это прошлый век, а identity — настоящее. Глава будет полезна всем, кто работает с PostgreSQL в проде — особенно backend-разработчикам, независимо от языка и фреймворка. Если вы проектируете схемы БД, пишете SQL-запросы или просто хотите избежать неприятных грабель — стоит прочитать.

https://habr.com/ru/articles/923572/

#postgresql #sql #оптимизация_кода #базы_данных

[Перевод] Почему Rust так мало волнует производительность компилятора

Наверно, чаще всего на Rust жалуются из-за его медленного цикла обратной связи и долгого времени компиляции. Я слышу и читаю об этом постоянно; в подкастах по Rust, в постах блогов , опросах , докладах с конференций и офлайн-обсуждениях. Я и сам, как пользователь Rust, регулярно жалуюсь на это! Кроме того, наряду с обычными жалобами на время компиляции, я начал замечать от раздражённых разработчиков на Rust и подобные заявления: «Почему Rust Project не занимается активнее этой важной и очевидной проблемой? Почему с этим что-нибудь не сделают?». Я участник рабочей группы по производительности компилятора Rust , поэтому воспринимаю такие вопросы очень серьёзно. И, разумеется, у меня есть мнение по этому поводу. В этом посте я приведу свои размышления, способные служить ответами на эти (и похожие) вопросы. Предупреждение: все выраженные в этом посте мнения исключительно мои и необязательно отражают точку зрения Rust Project (группы контрибьюторов и мейнтейнеров тулчейна Rust).

https://habr.com/ru/articles/918768/

#rustc #оптимизация_кода #опенсорс

10 лучших расширений VS Code для больших и малых групп, повышающих производительность

Если вы проводите большую часть дня в Visual Studio Code (как и я), то вы понимаете, что это больше, чем просто редактор кода. Это ваш настоящий командный центр, не меньше. С правильными расширениями VS Code может стать мощным инструментом, который повысит вашу производительность, обеспечит чистый код и даже сделает отладку (почти) безболезненной. Конечно, сейчас кто-то подумает, ну зачем мне нужны эти расширения? Установите, и вы поймете почему. Я собрал 10 расширений VS Code, которыми сам пользуюсь, и которые особенно будут полезны для корпоративных разработчиков, работающих над сложными, совместными и масштабными проектами. Независимо от того, сосредоточены ли вы на написании более чистого кода, раннем выявлении ошибок, оптимизации рабочих процессов Git или совместной работе с удаленными коллегами в режиме реального времени, здесь есть что-то, что сделает вашу жизнь кодирования более гладкой и быстрой.

https://habr.com/ru/articles/918286/

#vs_code #оптимизация_кода

[Перевод] Что будет, если компилятор станет встраивать код по максимуму

Усаживайтесь поудобнее, ребята! Сегодня мы с вами разберём следующий увлекательный вопрос: что будет, если заинлайнить вообще всё? Если вы пока не знакомы с техникой встраивания (inlining) то примите к сведению, что в сообществе специалистов по разработке компиляторов многие, в том числе очень авторитетные фигуры (например, Чендлер Каррут ) считают этот приём наиважнейшим при оптимизации компиляторов. Подробнее о том, как устроено встраивание, рассказано здесь — мы беззастенчиво хвалимся той презентацией, с которой выступили перед участниками конференции LLVM Developers' Meeting по межпроцедурной оптимизации. Я рассказывал о встраивании и очень рекомендую вам посмотреть хотя бы первые 6 минут. В этом видео я рассказываю, почему встраивание — очень простое преобразование, а вот тут вашему вниманию предлагается реализация встраивания, предложенная великим Крисом Латтнером уже около 20 лет назад — в ней всего около 200 строк кода. К сожалению, сегодня даже само преобразование пропорционально выросло: в качестве примера взгляните хотя бы на InlineFunction.cpp . В вышеупомянутом видео я рассказываю, что у встраивания есть свои недостатки . Иными словами, встраивание позиционируется как супер-пупер инструмент в арсенале компиляторщика, но пользоваться этой штукой следует с осторожностью. И следует ли вообще?

https://habr.com/ru/articles/916580/

#компиляторы #inline #высокая_производительность #с++ #оптимизация_кода