О скорости Python в часто используемых сценариях

В конце прошлой недели на python-ideas появилась очередная тема о производительности Питона — Why CPython is still behind in performance for some widely used patterns?

Автор, приведя отрывок кода, обращал внимание читающих на то, что производительность Python в 10 раз ниже, чем в таких языках как JavaScript, Java, C# и Go.

Там же он указал на то, что мелкие правки и кеширование локальной переменной ускорили код в 3-4 раза и на то, что вызов функций обходится очень дорого (впрочем, говорил он, в PyPy всё быстрее). В конце следовал вывод:

Если код, который вы пишите без раздумий, медленный, а при этом существует вариант ускорения, то с языком что-то не то.

Несмотря на избитость темы, обсуждение всё же получило продолжение. И вот какие ответы прозвучали:

• Нужно знать язык и писать именно в его терминах и стиле, а не нести что-то откуда-то. Не нужно в Питоне писать по-явовски, а в Яве по-питоньи.
• PyPy использует JIT, отсюда и оптимизация. Если поглядеть на степень распространения PyPy, то она не впечатляет, однако, если нужна скорость в обмен на совместимость с C/C++, то PyPy — альтернатива.
• Объектная модель JavaScript более проста. Java, C# и Go используют статическую типизацию, оптимизирующие компиляторы и простой механизм разрешения порядка методов.
• Чем гибче язык, тем труднее оптимизировать. Компилятор намеренно простой и неоптимизирующий (действия оптимизатора peephole минимальны). Его посыл: простота и скорость компиляции.
• Корректнее рассматривать язык вкупе со всей его экосистемой: многие неигрушечные проблемы решаются установкой подходящих пакетов.
• Ведутся работы в сторону упрощения механизмов для использования модулей-расширений, которые позволяют увеличить производительность. Кроме того, существуют F2PY (теперь в NumPy), Numba и Cython.

Лично мне очень близка позиция Барри Ворсоу, поэтому приведу его ответ на русском полностью:

Вот ещё одно видение: думаю, что многие проблемы «производительности» в реальности часто относятся не к скорости интерпретатора CPython, а к другим факторам. Да, конечно, я бы хотел, чтобы интерпретатор был быстрее, но, исходя из опыта, есть много более насущных проблем. По меньшей мере, проще для начала разрешить именно эти проблемы.

Это может быть что угодно: неподходящие алгоритмы, недостаток понимания того, как работает Питон, использование неэффективных структур данных, обращение к сети или другая работа на стадии импорта и пр. В итоге, я думаю, нужно следить за производительностью в боевой среде и решать конкретные проблемы.
Я, например, очень жду момента, когда смогу использовать -X importtime из Python 3.7, чтобы выявлять регрессию по времени при старте интерфейсов командной строки, регрессию, которая имеет тенденцию возникать из-за появления в глобальной области всяких нечаянных разностей.

Но есть и ещё одна весьма важная вещь, которую следует принимать во внимание, пусть она и очень редко всплывает в подобных обсуждениях — это продуктивность разработчика и его ощущения. Одной из вещей, которые делают Питон популярным и эффективным, я полагаю, является то, что он хорошо масштабируется в человеческом измерении: то есть, это отличный язык для одного человека, для небольшой команды и так далее до очень крупных организаций. И я убеждаюсь, что штуки на подобии аннотации типов чрезвычайно полезны на больших масштабах: добротно аннотированный код позволяет чрезвычайно быстро наращивать продуктивность, а всякие утилиты и среды разработки упрощают процесс аннотации.

Вот это часто недооценивают, а не должны бы! Закон Мура не распространяется на людей — нельзя эффективно или задёшево масштабироваться набрасыванием тел на проект. Питон — один из лучших языков (и экосистема!), позволяющий получать удовольствие от разработки, писать качественный и весьма производительный код.

Для тех, кого особенно сильно интересует тема оптимизаций, Виктор Стиннер сделал отличный ресурс — Faster CPython.


Теперь вы знаете, что ответить, тем у кого Питон медленный.