🕷️ Crawler Inspector

URL Lookup

Direct Parameter Lookup

Raw Queries and Responses

1. Shard Calculation

Query:

Response:

Calculated Shard: 134 (from laksa015)

2. Crawled Status Check

Query:

curl -X POST \
  'http://laksa134.int.ahrefs:8124/' \
  -H 'Content-Type: text/plain' \
  -H 'X-ClickHouse-Database: crawler3' \
  -H 'Authorization: Basic YXBpOg==' \
  -d 'SELECT getAhrefsURLFromUnparsed(src_unparsed) AS found_url, ifNull(toUnixTimestamp(download_stamp), 0) AS crawl_time, ifNull(toUnixTimestamp(props_url_first_seen), 0) AS first_indexed_time, download_http_code AS http_code, src_unparsed AS src_unparsed, src_root_hash AS src_root_hash, history_drop_reason AS history_drop_reason, meta_title AS meta_title, meta_descriptions AS meta_descriptions, attrs_boilerpipe_text AS attrs_boilerpipe_text, attrs_markdown AS attrs_markdown, attrs_readable_markdown AS attrs_readable_markdown, meta_canonical AS meta_canonical FROM crawler3.page_info_local FINAL PREWHERE (src_root_hash, src_unparsed) IN ((getAhrefsRootHashFromUnparsed(getAhrefsUnparsedNoserviceFromURL(\'https://habr.com/ru/companies/ruvds/articles/418823/\')), getAhrefsUnparsedNoserviceFromURL(\'https://habr.com/ru/companies/ruvds/articles/418823/\'))) FORMAT JSONEachRow'

Response:

{"found_url":"https:\/\/habr.com\/ru\/companies\/ruvds\/articles\/418823\/","crawl_time":1770765702,"first_indexed_time":1683365964,"http_code":200,"src_unparsed":"com,habr!\/ru\/companies\/ruvds\/articles\/418823\/ s443","src_root_hash":"14843476518697139734","history_drop_reason":null,"meta_title":"Python — это медленно. Почему? \/ Хабр","meta_descriptions":["В последнее время можно наблюдать рост популярности языка программирования Python. Он используется в DevOps, в анализе данных, в веб-разработке, в сфере безопасности и в других областях. Но вот..."],"attrs_boilerpipe_text":"Время на прочтение\n9 мин\nОхват и читатели\n92K\nПеревод\nВ последнее время можно наблюдать рост популярности языка программирования Python. Он используется в DevOps, в анализе данных, в веб-разработке, в сфере безопасности и в других областях. Но вот скорость… Здесь этому языку похвастаться нечем. Автор материала, перевод которого мы сегодня публикуем, решил выяснить причины медлительности Python и найти средства его ускорения.\nОбщие положения\nКак Java, в плане производительности, соотносится с C или C++? Как сравнить C# и Python? Ответы на эти вопросы серьёзно зависят от типа анализируемых исследователем приложений. Не существует идеального бенчмарка, но, изучая производительность программ, написанных на разных языках, неплохой\nотправной точкой\nможет стать проект The Computer Language Benchmarks Game.\nЯ ссылаюсь на The Computer Language Benchmarks Game уже больше десяти лет. Python, в сравнении с другими языками, такими, как Java, C#, Go, JavaScript, C++, является одним из\nсамых медленных\n. Сюда входят языки, в которых используется\nJIT\n-компиляция (C#, Java), и\nAOT\n-компиляция (C, C++), а также интерпретируемые языки, такие, как JavaScript.\nТут мне хотелось бы отметить, что говоря «Python», я имею в виду эталонную реализацию интерпретатора Python — CPython. В этом материале мы коснёмся и других его реализаций. Собственно говоря, здесь мне хочется найти ответ на вопрос о том, почему Python требуется в 2-10 раз больше времени, чем другим языкам, на решение сопоставимых задач, и о том, можно ли сделать его быстрее.\nВот основные теории, пытающиеся объяснить причины медленной работы Python:\nПричина этого — в GIL (Global Interpreter Lock, глобальная блокировка интерпретатора).\nПричина в том, что Python — это интерпретируемый, а не компилируемый язык.\nПричина — в динамической типизации.\nПроанализируем эти идеи и попытаемся найти ответ на вопрос о том, что сильнее всего оказывает влияние на производительность Python-приложений.\nGIL\nСовременные компьютеры обладают многоядерными процессорами, иногда встречаются и многопроцессорные системы. Для того чтобы использовать всю эту вычислительную мощь, операционная система применяет низкоуровневые структуры, называемые потоками, в то время как процессы (например — процесс браузера Chrome) могут запускать множество потоков и соответствующим образом их использовать. В результате, например, если какой-то процесс особенно сильно нуждается в ресурсах процессора, его выполнение может быть разделено между несколькими ядрами, что позволяет большинству приложений быстрее решать встающие перед ними задачи.\nНапример, у моего браузера Chrome, в тот момент, когда я это пишу, имеется 44 открытых потока. Тут стоит учитывать то, что структура и API системы работы с потоками различается в операционных системах, основанных на Posix (Mac OS, Linux), и в ОС семейства Windows. Операционная система, кроме того, занимается планированием работы потоков.\nЕсли раньше вы не встречались с многопоточным программированием, то сейчас вам нужно познакомиться с так называемыми блокировками (locks). Смысл блокировок заключается в том, что они позволяют обеспечить такое поведение системы, когда, в многопоточной среде, например, при изменении некоей переменной в памяти, доступ к одной и той же области памяти (для чтения или изменения) не могут одновременно получить несколько потоков.\nКогда интерпретатор CPython создаёт переменные, он выделяет память, а затем подсчитывает количество существующих ссылок на эти переменные. Эта концепция известна как подсчёт ссылок (reference counting). Если число ссылок равняется нулю, тогда соответствующий участок памяти освобождается. Именно поэтому, например, создание «временных» переменных, скажем, в пределах областей видимости циклов, не приводит к чрезмерному увеличению объёма памяти, потребляемого приложением.\nСамое интересное начинается тогда, когда одними и теми же переменными совместно пользуются несколько потоков, а главная проблема тут заключается в том, как именно CPython выполняет подсчёт ссылок. Тут и проявляется действие «глобальной блокировки интерпретатора», которая тщательно контролирует выполнение потоков.\nИнтерпретатор может выполнять лишь одну операцию за раз, независимо от того, как много потоков имеется в программе.\n▍Как GIL влияет на производительность Python-приложений?\nЕсли у нас имеется однопоточное приложение, работающее в одном процессе интерпретатора Python, то GIL никак на производительность не влияет. Если, например, избавиться от GIL, никакой разницы в производительности мы не заметим.\nЕсли же, в пределах одного процесса интерпретатора Python, надо реализовать параллельную обработку данных с применением механизмов многопоточности, и используемые потоки будут интенсивно использовать подсистему ввода-вывода (например, если они будут работать с сетью или с диском), тогда можно будет наблюдать последствия того, как GIL управляет потоками. Вот как это выглядит в случае использования двух потоков, интенсивно нагружающих процессов.\nВизуализация работы GIL (взято\nотсюда\n)\nЕсли у вас имеется веб-приложение (например, основанное на фреймворке Django), и вы используете WSGI, то каждый запрос к веб-приложению будет обслуживаться отдельным процессом интерпретатора Python, то есть, у нас имеется лишь 1 блокировка на запрос. Так как интерпретатор Python запускается медленно, в некоторых реализациях WSGI имеется так называемый «режим демона», при использовании которого\nпроцессы интерпретатора\nподдерживаются в рабочем состоянии, что позволяет системе быстрее обслуживать запросы.\n▍Как ведут себя другие интерпретаторы Python?\nВ\nPyPy\nесть GIL, он обычно более чем в 3 раза быстрее, чем CPython.\nВ\nJython\nнет GIL, так как потоки Python в Jython представлены в виде потоков Java. Такие потоки используют возможности по управлению памятью JVM.\n▍Как управление потоками организовано в JavaScript?\nЕсли говорить о JavaScript, то, в первую очередь, надо отметить, что все JS-движки используют алгоритм сборки мусора\nmark-and-sweep\n. Как уже было сказано, основная причина необходимости использования GIL — это алгоритм управления памятью, применяемый в CPython.\nВ JavaScript нет GIL, однако, JS — это однопоточный язык, поэтому в нём подобный механизм и не нужен. Вместо параллельного выполнения кода в JavaScript применяются методики асинхронного программирования, основанные на цикле событий, промисах и коллбэках. В Python есть нечто подобное, представленное модулем\nasyncio\n.\nPython — интерпретируемый язык\nМне часто приходилось слышать о том, что низкая производительность Python является следствием того, что это — интерпретируемый язык. Подобные утверждения основаны на грубом упрощении того, как, на самом деле, работает CPython. Если, в терминале, ввести команду вроде\npython myscript.py\n, тогда CPython начнёт длительную последовательность действий, которая заключается в чтении, лексическом анализе, парсинге, компиляции, интерпретации и выполнении кода скрипта. Если вас интересуют подробности — взгляните на\nэтот\nматериал.\nДля нас, при рассмотрении этого процесса, особенно важным является тот факт, что здесь, на стадии компиляции, создаётся\n.pyc\n-файл, и последовательность байт-кодов пишется в файл в директории\n__pycache__\/\n, которая используется и в Python 3, и в Python 2.\nПодобное применяется не только к написанным нами скриптам, но и к импортированному коду, включая сторонние модули.\nВ результате, большую часть времени (если только вы не пишете код, который запускается лишь один раз) Python занимается выполнением готового байт-кода. Если сравнить это с тем, что происходит в Java и в C#, окажется, что код на Java компилируется в «Intermediate Language», и виртуальная машина Java читает байт-код и выполняет его JIT-компиляцию в машинный код. «Промежуточный язык» .NET CIL (это то же самое, что .NET Common-Language-Runtime, CLR), использует JIT-компиляцию для перехода к машинному коду.\nВ результате, и в Java и в C# используется некий «промежуточный язык» и присутствуют похожие механизмы. Почему же тогда Python показывает в бенчмарках гораздо худшие результаты, чем Java и C#, если все эти языки используют виртуальные машины и какие-то разновидности байт-кода? В первую очередь — из-за того, что в .NET и в Java используется JIT-компиляция.\nJIT-компиляция (Just In Time compilation, компиляция «на лету» или «точно в срок») требует наличия промежуточного языка для того, чтобы позволить осуществлять разбиение кода на фрагменты (кадры). Системы AOT-компиляции (Ahead Of Time compilation, компиляция перед исполнением) спроектированы так, чтобы обеспечить полную работоспособность кода до того, как начнётся взаимодействие этого кода с системой.\nСамо по себе использование JIT не ускоряет выполнение кода, так как на выполнение поступают, как и в Python, некие фрагменты байт-кода. Однако JIT позволяет выполнять оптимизации кода в процессе его выполнения. Хороший JIT-оптимизатор способен выявить наиболее нагруженные части приложения (такую часть приложения называют «hot spot») и оптимизировать соответствующие фрагменты кода, заменив их оптимизированными и более производительными вариантами, чем те, что использовались ранее.\nЭто означает, что когда некое приложение снова и снова выполняет некие действия, подобная оптимизация способна значительно ускорить выполнение таких действий. Кроме того, не забывайте о том, что Java и C# — это языки со строгой типизацией, поэтому оптимизатор может делать о коде больше предположений, способствующих улучшению производительности программ.\nJIT-компилятор есть в PyPy, и, как уже было сказано, эта реализация интерпретатора Python гораздо быстрее, чем CPython. Сведения, касающиеся сравнения разных интерпретаторов Python, можно найти в\nэтом\nматериале.\n▍Почему в CPython не используется JIT-компилятор?\nУ JIT-компиляторов есть и недостатки. Один из них — время запуска. CPython и так запускается сравнительно медленно, а PyPy в 2-3 раза медленнее, чем CPython. Длительное время запуска JVM — это тоже известный факт. CLR .NET обходит эту проблему, запускаясь в ходе загрузки системы, но тут надо отметить, что и CLR, и та операционная система, в которой запускается CLR, разрабатываются одной и той же компанией.\nЕсли у вас имеется один процесс Python, который работает длительное время, при этом в таком процессе имеется код, который может быть оптимизирован, так как он содержит интенсивно используемые участки, тогда вам стоит серьёзно взглянуть на интерпретатор, имеющий JIT-компилятор.\nОднако, CPython — это реализация интерпретатора Python общего назначения. Поэтому, если вы разрабатываете, с использованием Python, приложения командной строки, то необходимость длительного ожидания запуска JIT-компилятора при каждом запуске этого приложения сильно замедлит работу.\nCPython пытается обеспечить поддержку как можно большего количества вариантов использования Python. Например, существует возможности подключения JIT-компилятора к Python, правда,\nпроект\n, в рамках которого реализуется эта идея, развивается не особенно активно.\nВ результате можно сказать, что если вы, с помощью Python, пишете программу, производительность которой может улучшиться при использовании JIT-компилятора — используйте интерпретатор PyPy.\nPython — динамически типизированный язык\nВ статически типизированных языках, при объявлении переменных, необходимо указывать их типы. Среди таких языков можно отметить C, C++, Java, C#, Go.\nВ динамически типизированных языках понятие типа данных имеет тот же смысл, но тип переменной является динамическим.\na = 1\na = \"foo\"\nВ этом простейшем примере Python сначала создаёт первую переменную\na\n, потом — вторую с тем же именем, имеющую тип\nstr\n, и освобождает память, которая была выделена первой переменной\na\n.\nМожет показаться, что писать на языках с динамической типизацией удобнее и проще, чем на языках со статической типизацией, однако, такие языки созданы не по чьей-то прихоти. При их разработке учтены особенности работы компьютерных систем. Всё, что написано в тексте программы, в итоге, сводится к инструкциям процессора. Это означает, что данные, используемые программой, например, в виде объектов или других типов данных, тоже преобразуются к низкоуровневым структурам.\nPython выполняет подобные преобразования автоматически, программист этих процессов не видит, и заботиться о подобных преобразованиях ему не нужно.\nОтсутствие необходимости указывать тип переменной при её объявлении — это не та особенность языка, которая делает Python медленным. Архитектура языка позволяет сделать динамическим практически всё, что угодно. Например, во время выполнения программы можно заменять методы объектов. Опять же, во время выполнения программы можно использовать технику «обезьяньих патчей» в применении к низкоуровневым системным вызовам. В Python возможно практически всё.\nИменно архитектура Python чрезвычайно усложняет оптимизацию.\nДля того чтобы проиллюстрировать эту идею, я собираюсь воспользоваться инструментом для трассировки системных вызовов в MacOS, который называется DTrace.\nВ готовом дистрибутиве CPython нет механизмов поддержки DTrace, поэтому CPython нужно будет перекомпилировать с соответствующими настройками. Тут используется версия 3.6.6. Итак, воспользуемся следующей последовательностью действий:\nwget https:\/\/github.com\/python\/cpython\/archive\/v3.6.6.zip\nunzip v3.6.6.zip\ncd v3.6.6\n.\/configure --with-dtrace\nmake\nТеперь, пользуясь\npython.exe\n, можно применять DTRace для трассировки кода. Об использовании DTrace с Python можно почитать\nздесь\n. А вот\nтут\nможно найти скрипты для измерения с помощью DTrace различных показателей работы Python-программ. Среди них — параметры вызова функций, время выполнения программ, время использования процессора, сведения о системных вызовах и так далее. Вот как пользоваться командой\ndtrace\n:\nsudo dtrace -s toolkit\/<tracer>.d -c ‘..\/cpython\/python.exe script.py’\nА вот как средство трассировки\npy_callflow\nпоказывает вызовы функций в приложении.\nТрассировка с использованием DTrace\nТеперь ответим на вопрос о том, влияет ли динамическая типизация на производительность Python. Вот некоторые соображения по этому поводу:\nПроверка и конверсия типов — операции тяжёлые. Каждый раз, когда выполняется обращение к переменной, её чтение или запись, производится проверка типа.\nЯзык, обладающей подобной гибкостью, сложно оптимизировать. Причина, по которой другие языки настолько быстрее Python, заключается в том, что они идут на те или иные компромиссы, выбирая между гибкостью и производительностью.\nПроект\nCython\nобъединяет Python и статическую типизацию, что, например, как показано в\nэтом материале\n, приводит к 84-кратному росту производительности в сравнении с применением обычного Python. Обратите внимание на этот проект, если вам нужна скорость.\nИтоги\nПричиной невысокой производительности Python является его динамическая природа и универсальность. Его можно использовать как инструмент для решения разнообразнейших задач. Для достижения тех же целей можно попытаться поискать более производительные, лучше оптимизированные инструменты. Возможно, найти их удастся, возможно — нет.\nПриложения, написанные на Python, можно оптимизировать, используя возможности по асинхронному выполнению кода, инструменты профилирования, и — правильно подбирая интерпретатор. Так, для оптимизации скорости работы приложений, время запуска которых неважно, а производительность которых может выиграть от использования JIT-компилятора, рассмотрите возможность использования PyPy. Если вам нужна максимальная производительность и вы готовы к ограничениям статической типизации — взгляните на Cython.\nУважаемые читатели!\nКак вы решаете проблемы невысокой производительности Python?","attrs_markdown":"[Все потоки](https:\/\/habr.com\/ru\/articles\/)\n\n[Войти](https:\/\/habr.com\/kek\/v1\/auth\/habrahabr\/?back=\/ru\/companies\/ruvds\/articles\/418823\/&hl=ru)\n\n[![](https:\/\/habrastorage.org\/getpro\/habr\/branding\/937\/973\/199\/9379731999358877e1a6e6fa2423bcc8.png)](https:\/\/ruvds.com\/ru-rub?utm_source=habr&utm_medium=banner&utm_campaign=promo&utm_content=link&?erid=LjN8KAR3S)\n\n[![](https:\/\/habrastorage.org\/getpro\/habr\/company\/608\/f02\/206\/608f0220675e20da793aa1974a1a0a2e.png)](https:\/\/habr.com\/ru\/companies\/ruvds\/profile\/)\n\n3301\\.3\n\nОбщий рейтинг\n\n[RUVDS.com](https:\/\/habr.com\/ru\/companies\/ruvds\/profile\/)\n\nVDS\/VPS-хостинг. Скидка 15% по коду **HABR15**\n\nПодписаться\n\n[![](https:\/\/habrastorage.org\/r\/w48\/getpro\/habr\/avatars\/1b8\/7ff\/39c\/1b87ff39ce6dfc7224cb45ab05384ecc.png)](https:\/\/habr.com\/ru\/users\/ru_vds\/)\n\n[ru\\_vds](https:\/\/habr.com\/ru\/users\/ru_vds\/)\n\n1 авг 2018 в 09:26\n# Python — это медленно. Почему?\n9 мин\n\n92K\n\n[Блог компании RUVDS.com](https:\/\/habr.com\/ru\/companies\/ruvds\/articles\/)[Python \\*](https:\/\/habr.com\/ru\/hubs\/python\/) [Веб-разработка \\*](https:\/\/habr.com\/ru\/hubs\/webdev\/)\n\nПеревод\n\n[Автор оригинала: Anthony Shaw](https:\/\/hackernoon.com\/why-is-python-so-slow-e5074b6fe55b)\n\nВ последнее время можно наблюдать рост популярности языка программирования Python. Он используется в DevOps, в анализе данных, в веб-разработке, в сфере безопасности и в других областях. Но вот скорость… Здесь этому языку похвастаться нечем. Автор материала, перевод которого мы сегодня публикуем, решил выяснить причины медлительности Python и найти средства его ускорения.  \n   \n [![](https:\/\/habrastorage.org\/r\/w1560\/webt\/tv\/zp\/uz\/tvzpuzzfhsgdyegpe8ri3pbl3mw.jpeg)](https:\/\/habr.com\/company\/ruvds\/blog\/418823\/)\n\n## Общие положения\nКак Java, в плане производительности, соотносится с C или C++? Как сравнить C\\# и Python? Ответы на эти вопросы серьёзно зависят от типа анализируемых исследователем приложений. Не существует идеального бенчмарка, но, изучая производительность программ, написанных на разных языках, неплохой [отправной точкой](http:\/\/algs4.cs.princeton.edu\/faq\/) может стать проект The Computer Language Benchmarks Game.  \n   \n Я ссылаюсь на The Computer Language Benchmarks Game уже больше десяти лет. Python, в сравнении с другими языками, такими, как Java, C\\#, Go, JavaScript, C++, является одним из [самых медленных](https:\/\/benchmarksgame-team.pages.debian.net\/benchmarksgame\/faster\/python.html). Сюда входят языки, в которых используется [JIT](https:\/\/en.wikipedia.org\/wiki\/Just-in-time_compilation)\\-компиляция (C\\#, Java), и [AOT](https:\/\/en.wikipedia.org\/wiki\/Ahead-of-time_compilation)\\-компиляция (C, C++), а также интерпретируемые языки, такие, как JavaScript.  \n   \n Тут мне хотелось бы отметить, что говоря «Python», я имею в виду эталонную реализацию интерпретатора Python — CPython. В этом материале мы коснёмся и других его реализаций. Собственно говоря, здесь мне хочется найти ответ на вопрос о том, почему Python требуется в 2-10 раз больше времени, чем другим языкам, на решение сопоставимых задач, и о том, можно ли сделать его быстрее.  \n   \n Вот основные теории, пытающиеся объяснить причины медленной работы Python:\n\n- Причина этого — в GIL (Global Interpreter Lock, глобальная блокировка интерпретатора).\n- Причина в том, что Python — это интерпретируемый, а не компилируемый язык.\n- Причина — в динамической типизации.\n\nПроанализируем эти идеи и попытаемся найти ответ на вопрос о том, что сильнее всего оказывает влияние на производительность Python-приложений.\n\n## GIL\nСовременные компьютеры обладают многоядерными процессорами, иногда встречаются и многопроцессорные системы. Для того чтобы использовать всю эту вычислительную мощь, операционная система применяет низкоуровневые структуры, называемые потоками, в то время как процессы (например — процесс браузера Chrome) могут запускать множество потоков и соответствующим образом их использовать. В результате, например, если какой-то процесс особенно сильно нуждается в ресурсах процессора, его выполнение может быть разделено между несколькими ядрами, что позволяет большинству приложений быстрее решать встающие перед ними задачи.  \n   \n Например, у моего браузера Chrome, в тот момент, когда я это пишу, имеется 44 открытых потока. Тут стоит учитывать то, что структура и API системы работы с потоками различается в операционных системах, основанных на Posix (Mac OS, Linux), и в ОС семейства Windows. Операционная система, кроме того, занимается планированием работы потоков.  \n   \n Если раньше вы не встречались с многопоточным программированием, то сейчас вам нужно познакомиться с так называемыми блокировками (locks). Смысл блокировок заключается в том, что они позволяют обеспечить такое поведение системы, когда, в многопоточной среде, например, при изменении некоей переменной в памяти, доступ к одной и той же области памяти (для чтения или изменения) не могут одновременно получить несколько потоков.  \n   \n Когда интерпретатор CPython создаёт переменные, он выделяет память, а затем подсчитывает количество существующих ссылок на эти переменные. Эта концепция известна как подсчёт ссылок (reference counting). Если число ссылок равняется нулю, тогда соответствующий участок памяти освобождается. Именно поэтому, например, создание «временных» переменных, скажем, в пределах областей видимости циклов, не приводит к чрезмерному увеличению объёма памяти, потребляемого приложением.  \n   \n Самое интересное начинается тогда, когда одними и теми же переменными совместно пользуются несколько потоков, а главная проблема тут заключается в том, как именно CPython выполняет подсчёт ссылок. Тут и проявляется действие «глобальной блокировки интерпретатора», которая тщательно контролирует выполнение потоков.  \n   \n Интерпретатор может выполнять лишь одну операцию за раз, независимо от того, как много потоков имеется в программе.\n\n### ▍Как GIL влияет на производительность Python-приложений?\nЕсли у нас имеется однопоточное приложение, работающее в одном процессе интерпретатора Python, то GIL никак на производительность не влияет. Если, например, избавиться от GIL, никакой разницы в производительности мы не заметим.  \n   \n Если же, в пределах одного процесса интерпретатора Python, надо реализовать параллельную обработку данных с применением механизмов многопоточности, и используемые потоки будут интенсивно использовать подсистему ввода-вывода (например, если они будут работать с сетью или с диском), тогда можно будет наблюдать последствия того, как GIL управляет потоками. Вот как это выглядит в случае использования двух потоков, интенсивно нагружающих процессов.\n\n![](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/post_images\/f9e\/379\/f47\/f9e379f4724ba48881f53b489ca5ed1d.png)\n\n*Визуализация работы GIL (взято [отсюда](http:\/\/dabeaz.blogspot.com\/2010\/01\/python-gil-visualized.html))*  \n   \n Если у вас имеется веб-приложение (например, основанное на фреймворке Django), и вы используете WSGI, то каждый запрос к веб-приложению будет обслуживаться отдельным процессом интерпретатора Python, то есть, у нас имеется лишь 1 блокировка на запрос. Так как интерпретатор Python запускается медленно, в некоторых реализациях WSGI имеется так называемый «режим демона», при использовании которого [процессы интерпретатора](https:\/\/www.slideshare.net\/GrahamDumpleton\/secrets-of-a-wsgi-master) поддерживаются в рабочем состоянии, что позволяет системе быстрее обслуживать запросы.\n\n### ▍Как ведут себя другие интерпретаторы Python?\nВ [PyPy](http:\/\/doc.pypy.org\/en\/latest\/faq.html#does-pypy-have-a-gil-why) есть GIL, он обычно более чем в 3 раза быстрее, чем CPython.  \n   \n В [Jython](http:\/\/www.jython.org\/jythonbook\/en\/1.0\/Concurrency.html#no-global-interpreter-lock) нет GIL, так как потоки Python в Jython представлены в виде потоков Java. Такие потоки используют возможности по управлению памятью JVM.\n\n### ▍Как управление потоками организовано в JavaScript?\nЕсли говорить о JavaScript, то, в первую очередь, надо отметить, что все JS-движки используют алгоритм сборки мусора [mark-and-sweep](https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/JavaScript\/Memory_Management). Как уже было сказано, основная причина необходимости использования GIL — это алгоритм управления памятью, применяемый в CPython.  \n   \n В JavaScript нет GIL, однако, JS — это однопоточный язык, поэтому в нём подобный механизм и не нужен. Вместо параллельного выполнения кода в JavaScript применяются методики асинхронного программирования, основанные на цикле событий, промисах и коллбэках. В Python есть нечто подобное, представленное модулем `asyncio`.\n\n## Python — интерпретируемый язык\nМне часто приходилось слышать о том, что низкая производительность Python является следствием того, что это — интерпретируемый язык. Подобные утверждения основаны на грубом упрощении того, как, на самом деле, работает CPython. Если, в терминале, ввести команду вроде `python myscript.py`, тогда CPython начнёт длительную последовательность действий, которая заключается в чтении, лексическом анализе, парсинге, компиляции, интерпретации и выполнении кода скрипта. Если вас интересуют подробности — взгляните на [этот](https:\/\/hackernoon.com\/modifying-the-python-language-in-7-minutes-b94b0a99ce14) материал.  \n   \n Для нас, при рассмотрении этого процесса, особенно важным является тот факт, что здесь, на стадии компиляции, создаётся `.pyc`\\-файл, и последовательность байт-кодов пишется в файл в директории `__pycache__\/`, которая используется и в Python 3, и в Python 2.  \n   \n Подобное применяется не только к написанным нами скриптам, но и к импортированному коду, включая сторонние модули.  \n   \n В результате, большую часть времени (если только вы не пишете код, который запускается лишь один раз) Python занимается выполнением готового байт-кода. Если сравнить это с тем, что происходит в Java и в C\\#, окажется, что код на Java компилируется в «Intermediate Language», и виртуальная машина Java читает байт-код и выполняет его JIT-компиляцию в машинный код. «Промежуточный язык» .NET CIL (это то же самое, что .NET Common-Language-Runtime, CLR), использует JIT-компиляцию для перехода к машинному коду.   \n   \n В результате, и в Java и в C\\# используется некий «промежуточный язык» и присутствуют похожие механизмы. Почему же тогда Python показывает в бенчмарках гораздо худшие результаты, чем Java и C\\#, если все эти языки используют виртуальные машины и какие-то разновидности байт-кода? В первую очередь — из-за того, что в .NET и в Java используется JIT-компиляция.  \n   \n JIT-компиляция (Just In Time compilation, компиляция «на лету» или «точно в срок») требует наличия промежуточного языка для того, чтобы позволить осуществлять разбиение кода на фрагменты (кадры). Системы AOT-компиляции (Ahead Of Time compilation, компиляция перед исполнением) спроектированы так, чтобы обеспечить полную работоспособность кода до того, как начнётся взаимодействие этого кода с системой.  \n   \n Само по себе использование JIT не ускоряет выполнение кода, так как на выполнение поступают, как и в Python, некие фрагменты байт-кода. Однако JIT позволяет выполнять оптимизации кода в процессе его выполнения. Хороший JIT-оптимизатор способен выявить наиболее нагруженные части приложения (такую часть приложения называют «hot spot») и оптимизировать соответствующие фрагменты кода, заменив их оптимизированными и более производительными вариантами, чем те, что использовались ранее.  \n   \n Это означает, что когда некое приложение снова и снова выполняет некие действия, подобная оптимизация способна значительно ускорить выполнение таких действий. Кроме того, не забывайте о том, что Java и C\\# — это языки со строгой типизацией, поэтому оптимизатор может делать о коде больше предположений, способствующих улучшению производительности программ.  \n   \n JIT-компилятор есть в PyPy, и, как уже было сказано, эта реализация интерпретатора Python гораздо быстрее, чем CPython. Сведения, касающиеся сравнения разных интерпретаторов Python, можно найти в [этом](https:\/\/hackernoon.com\/which-is-the-fastest-version-of-python-2ae7c61a6b2b) материале.\n\n### ▍Почему в CPython не используется JIT-компилятор?\nУ JIT-компиляторов есть и недостатки. Один из них — время запуска. CPython и так запускается сравнительно медленно, а PyPy в 2-3 раза медленнее, чем CPython. Длительное время запуска JVM — это тоже известный факт. CLR .NET обходит эту проблему, запускаясь в ходе загрузки системы, но тут надо отметить, что и CLR, и та операционная система, в которой запускается CLR, разрабатываются одной и той же компанией.  \n   \n Если у вас имеется один процесс Python, который работает длительное время, при этом в таком процессе имеется код, который может быть оптимизирован, так как он содержит интенсивно используемые участки, тогда вам стоит серьёзно взглянуть на интерпретатор, имеющий JIT-компилятор.  \n   \n Однако, CPython — это реализация интерпретатора Python общего назначения. Поэтому, если вы разрабатываете, с использованием Python, приложения командной строки, то необходимость длительного ожидания запуска JIT-компилятора при каждом запуске этого приложения сильно замедлит работу.  \n   \n CPython пытается обеспечить поддержку как можно большего количества вариантов использования Python. Например, существует возможности подключения JIT-компилятора к Python, правда, [проект](https:\/\/www.slideshare.net\/AnthonyShaw5\/pyjion-a-jit-extension-system-for-cpython), в рамках которого реализуется эта идея, развивается не особенно активно.  \n   \n В результате можно сказать, что если вы, с помощью Python, пишете программу, производительность которой может улучшиться при использовании JIT-компилятора — используйте интерпретатор PyPy.\n\n## Python — динамически типизированный язык\nВ статически типизированных языках, при объявлении переменных, необходимо указывать их типы. Среди таких языков можно отметить C, C++, Java, C\\#, Go.  \n   \n В динамически типизированных языках понятие типа данных имеет тот же смысл, но тип переменной является динамическим.\n```\n\n```\nВ этом простейшем примере Python сначала создаёт первую переменную `a`, потом — вторую с тем же именем, имеющую тип `str`, и освобождает память, которая была выделена первой переменной `a`.  \n   \n Может показаться, что писать на языках с динамической типизацией удобнее и проще, чем на языках со статической типизацией, однако, такие языки созданы не по чьей-то прихоти. При их разработке учтены особенности работы компьютерных систем. Всё, что написано в тексте программы, в итоге, сводится к инструкциям процессора. Это означает, что данные, используемые программой, например, в виде объектов или других типов данных, тоже преобразуются к низкоуровневым структурам.  \n   \n Python выполняет подобные преобразования автоматически, программист этих процессов не видит, и заботиться о подобных преобразованиях ему не нужно.  \n   \n Отсутствие необходимости указывать тип переменной при её объявлении — это не та особенность языка, которая делает Python медленным. Архитектура языка позволяет сделать динамическим практически всё, что угодно. Например, во время выполнения программы можно заменять методы объектов. Опять же, во время выполнения программы можно использовать технику «обезьяньих патчей» в применении к низкоуровневым системным вызовам. В Python возможно практически всё.  \n   \n Именно архитектура Python чрезвычайно усложняет оптимизацию.  \n   \n Для того чтобы проиллюстрировать эту идею, я собираюсь воспользоваться инструментом для трассировки системных вызовов в MacOS, который называется DTrace.  \n   \n В готовом дистрибутиве CPython нет механизмов поддержки DTrace, поэтому CPython нужно будет перекомпилировать с соответствующими настройками. Тут используется версия 3.6.6. Итак, воспользуемся следующей последовательностью действий:\n```\n\n```\nТеперь, пользуясь `python.exe`, можно применять DTRace для трассировки кода. Об использовании DTrace с Python можно почитать [здесь](https:\/\/github.com\/paulross\/dtrace-py#the-lightning-talk). А вот [тут](https:\/\/github.com\/paulross\/dtrace-py\/tree\/master\/toolkit) можно найти скрипты для измерения с помощью DTrace различных показателей работы Python-программ. Среди них — параметры вызова функций, время выполнения программ, время использования процессора, сведения о системных вызовах и так далее. Вот как пользоваться командой `dtrace`:\n```\nsudo dtrace -s toolkit\/<tracer>.d -c ‘..\/cpython\/python.exe script.py’\n```\nА вот как средство трассировки `py_callflow` показывает вызовы функций в приложении.\n\n![](https:\/\/habrastorage.org\/getpro\/habr\/post_images\/13e\/bd4\/926\/13ebd492636a94b23400305293aec346.gif)\n\n*Трассировка с использованием DTrace*  \n   \n Теперь ответим на вопрос о том, влияет ли динамическая типизация на производительность Python. Вот некоторые соображения по этому поводу:\n\n- Проверка и конверсия типов — операции тяжёлые. Каждый раз, когда выполняется обращение к переменной, её чтение или запись, производится проверка типа.\n- Язык, обладающей подобной гибкостью, сложно оптимизировать. Причина, по которой другие языки настолько быстрее Python, заключается в том, что они идут на те или иные компромиссы, выбирая между гибкостью и производительностью.\n- Проект [Cython](http:\/\/cython.org\/) объединяет Python и статическую типизацию, что, например, как показано в [этом материале](http:\/\/notes-on-cython.readthedocs.io\/en\/latest\/std_dev.html), приводит к 84-кратному росту производительности в сравнении с применением обычного Python. Обратите внимание на этот проект, если вам нужна скорость.\n## Итоги\nПричиной невысокой производительности Python является его динамическая природа и универсальность. Его можно использовать как инструмент для решения разнообразнейших задач. Для достижения тех же целей можно попытаться поискать более производительные, лучше оптимизированные инструменты. Возможно, найти их удастся, возможно — нет.  \n   \n Приложения, написанные на Python, можно оптимизировать, используя возможности по асинхронному выполнению кода, инструменты профилирования, и — правильно подбирая интерпретатор. Так, для оптимизации скорости работы приложений, время запуска которых неважно, а производительность которых может выиграть от использования JIT-компилятора, рассмотрите возможность использования PyPy. Если вам нужна максимальная производительность и вы готовы к ограничениям статической типизации — взгляните на Cython.  \n   \n **Уважаемые читатели\\!** Как вы решаете проблемы невысокой производительности Python?  \n   \n [![](https:\/\/habrastorage.org\/r\/w1560\/files\/1ba\/550\/d25\/1ba550d25e8846ce8805de564da6aa63.png)](https:\/\/ruvds.com\/ru-rub\/#order)\n\nТеги:\n\n- [Python](https:\/\/habr.com\/ru\/search\/?target_type=posts&order=relevance&q=[Python])\n- [разработка](https:\/\/habr.com\/ru\/search\/?target_type=posts&order=relevance&q=[%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0])\n\nХабы:\n\n- [Блог компании RUVDS.com](https:\/\/habr.com\/ru\/companies\/ruvds\/articles\/)\n- [Python](https:\/\/habr.com\/ru\/hubs\/python\/)\n- [Веб-разработка](https:\/\/habr.com\/ru\/hubs\/webdev\/)\n\n\\+48\n\n253\n\n[56](https:\/\/habr.com\/ru\/companies\/ruvds\/articles\/418823\/comments\/)\n\n[![](https:\/\/habrastorage.org\/getpro\/habr\/company\/608\/f02\/206\/608f0220675e20da793aa1974a1a0a2e.png)](https:\/\/habr.com\/ru\/companies\/ruvds\/profile\/)\n\n[RUVDS.com](https:\/\/habr.com\/ru\/companies\/ruvds\/profile\/)\n\nVDS\/VPS-хостинг. Скидка 15% по коду **HABR15**\n\n[Telegram](https:\/\/telegram.me\/ruvds_community)[ВКонтакте](https:\/\/vk.com\/ru_vds)[X](https:\/\/x.com\/ru_vds)\n\n[![](https:\/\/habrastorage.org\/getpro\/habr\/avatars\/1b8\/7ff\/39c\/1b87ff39ce6dfc7224cb45ab05384ecc.png)](https:\/\/habr.com\/ru\/users\/ru_vds\/)\n\n610\n\nКарма\n\n27\\.2\n\nОбщий рейтинг\n\n[@ru\\_vds](https:\/\/habr.com\/ru\/users\/ru_vds\/)\n\nПользователь\n\nПодписаться\n\n[Комментарии 56](https:\/\/habr.com\/ru\/companies\/ruvds\/articles\/418823\/comments\/)\n\n## Публикации\nЛучшие за сутки\n\nПохожие\n\n## Информация\nСайт\n\n[ruvds.com](https:\/\/ruvds.com\/)\n\nДата регистрации\n\n18 марта 2016\n\nДата основания\n\n27 июля 2015\n\nЧисленность\n\n11–30 человек\n\nМестоположение\n\nРоссия\n\nПредставитель\n\n[ruvds](https:\/\/habr.com\/ru\/users\/ruvds\/)\n\nВаш аккаунт\n\n- [Войти](https:\/\/habr.com\/kek\/v1\/auth\/habrahabr\/?back=\/ru\/companies\/ruvds\/articles\/418823\/&hl=ru)\n- [Регистрация](https:\/\/habr.com\/kek\/v1\/auth\/habrahabr-register\/?back=\/ru\/companies\/ruvds\/articles\/418823\/&hl=ru)\n\nРазделы\n\n- [Статьи](https:\/\/habr.com\/ru\/articles\/)\n- [Новости](https:\/\/habr.com\/ru\/news\/)\n- [Хабы](https:\/\/habr.com\/ru\/hubs\/)\n- [Компании](https:\/\/habr.com\/ru\/companies\/)\n- [Авторы](https:\/\/habr.com\/ru\/users\/)\n- [Песочница](https:\/\/habr.com\/ru\/sandbox\/)\n\nИнформация\n\n- [Устройство сайта](https:\/\/habr.com\/ru\/docs\/help\/)\n- [Для авторов](https:\/\/habr.com\/ru\/docs\/authors\/codex\/)\n- [Для компаний](https:\/\/habr.com\/ru\/docs\/companies\/corpblogs\/)\n- [Документы](https:\/\/habr.com\/ru\/docs\/docs\/transparency\/)\n- [Соглашение](https:\/\/account.habr.com\/info\/agreement\/?hl=ru_RU)\n- [Конфиденциальность](https:\/\/account.habr.com\/info\/confidential\/?hl=ru_RU)\n\nУслуги\n\n- [Корпоративный блог](https:\/\/company.habr.com\/ru\/corporate-blogs\/)\n- [Медийная реклама](https:\/\/company.habr.com\/ru\/advertising\/)\n- [Нативные проекты](https:\/\/company.habr.com\/ru\/native-special\/)\n- [Образовательные программы](https:\/\/company.habr.com\/ru\/education-programs\/)\n- [Стартапам](https:\/\/company.habr.com\/ru\/hello-startup\/)\n\nНастройка языка\n\n[Техническая поддержка](https:\/\/habr.com\/ru\/feedback\/)\n\n© 2006–2026, [Habr](https:\/\/company.habr.com\/)","attrs_readable_markdown":"9 мин\n\n92K\n\nПеревод\n\nВ последнее время можно наблюдать рост популярности языка программирования Python. Он используется в DevOps, в анализе данных, в веб-разработке, в сфере безопасности и в других областях. Но вот скорость… Здесь этому языку похвастаться нечем. Автор материала, перевод которого мы сегодня публикуем, решил выяснить причины медлительности Python и найти средства его ускорения.\n\n[![](https:\/\/habrastorage.org\/r\/w1560\/webt\/tv\/zp\/uz\/tvzpuzzfhsgdyegpe8ri3pbl3mw.jpeg)](https:\/\/habr.com\/company\/ruvds\/blog\/418823\/)\n\n## Общие положения\nКак Java, в плане производительности, соотносится с C или C++? Как сравнить C\\# и Python? Ответы на эти вопросы серьёзно зависят от типа анализируемых исследователем приложений. Не существует идеального бенчмарка, но, изучая производительность программ, написанных на разных языках, неплохой [отправной точкой](http:\/\/algs4.cs.princeton.edu\/faq\/) может стать проект The Computer Language Benchmarks Game.\n\nЯ ссылаюсь на The Computer Language Benchmarks Game уже больше десяти лет. Python, в сравнении с другими языками, такими, как Java, C\\#, Go, JavaScript, C++, является одним из [самых медленных](https:\/\/benchmarksgame-team.pages.debian.net\/benchmarksgame\/faster\/python.html). Сюда входят языки, в которых используется [JIT](https:\/\/en.wikipedia.org\/wiki\/Just-in-time_compilation)\\-компиляция (C\\#, Java), и [AOT](https:\/\/en.wikipedia.org\/wiki\/Ahead-of-time_compilation)\\-компиляция (C, C++), а также интерпретируемые языки, такие, как JavaScript.\n\nТут мне хотелось бы отметить, что говоря «Python», я имею в виду эталонную реализацию интерпретатора Python — CPython. В этом материале мы коснёмся и других его реализаций. Собственно говоря, здесь мне хочется найти ответ на вопрос о том, почему Python требуется в 2-10 раз больше времени, чем другим языкам, на решение сопоставимых задач, и о том, можно ли сделать его быстрее.\n\nВот основные теории, пытающиеся объяснить причины медленной работы Python:\n\n- Причина этого — в GIL (Global Interpreter Lock, глобальная блокировка интерпретатора).\n- Причина в том, что Python — это интерпретируемый, а не компилируемый язык.\n- Причина — в динамической типизации.\n\nПроанализируем эти идеи и попытаемся найти ответ на вопрос о том, что сильнее всего оказывает влияние на производительность Python-приложений.\n\n## GIL\nСовременные компьютеры обладают многоядерными процессорами, иногда встречаются и многопроцессорные системы. Для того чтобы использовать всю эту вычислительную мощь, операционная система применяет низкоуровневые структуры, называемые потоками, в то время как процессы (например — процесс браузера Chrome) могут запускать множество потоков и соответствующим образом их использовать. В результате, например, если какой-то процесс особенно сильно нуждается в ресурсах процессора, его выполнение может быть разделено между несколькими ядрами, что позволяет большинству приложений быстрее решать встающие перед ними задачи.\n\nНапример, у моего браузера Chrome, в тот момент, когда я это пишу, имеется 44 открытых потока. Тут стоит учитывать то, что структура и API системы работы с потоками различается в операционных системах, основанных на Posix (Mac OS, Linux), и в ОС семейства Windows. Операционная система, кроме того, занимается планированием работы потоков.\n\nЕсли раньше вы не встречались с многопоточным программированием, то сейчас вам нужно познакомиться с так называемыми блокировками (locks). Смысл блокировок заключается в том, что они позволяют обеспечить такое поведение системы, когда, в многопоточной среде, например, при изменении некоей переменной в памяти, доступ к одной и той же области памяти (для чтения или изменения) не могут одновременно получить несколько потоков.\n\nКогда интерпретатор CPython создаёт переменные, он выделяет память, а затем подсчитывает количество существующих ссылок на эти переменные. Эта концепция известна как подсчёт ссылок (reference counting). Если число ссылок равняется нулю, тогда соответствующий участок памяти освобождается. Именно поэтому, например, создание «временных» переменных, скажем, в пределах областей видимости циклов, не приводит к чрезмерному увеличению объёма памяти, потребляемого приложением.\n\nСамое интересное начинается тогда, когда одними и теми же переменными совместно пользуются несколько потоков, а главная проблема тут заключается в том, как именно CPython выполняет подсчёт ссылок. Тут и проявляется действие «глобальной блокировки интерпретатора», которая тщательно контролирует выполнение потоков.\n\nИнтерпретатор может выполнять лишь одну операцию за раз, независимо от того, как много потоков имеется в программе.\n\n### ▍Как GIL влияет на производительность Python-приложений?\nЕсли у нас имеется однопоточное приложение, работающее в одном процессе интерпретатора Python, то GIL никак на производительность не влияет. Если, например, избавиться от GIL, никакой разницы в производительности мы не заметим.\n\nЕсли же, в пределах одного процесса интерпретатора Python, надо реализовать параллельную обработку данных с применением механизмов многопоточности, и используемые потоки будут интенсивно использовать подсистему ввода-вывода (например, если они будут работать с сетью или с диском), тогда можно будет наблюдать последствия того, как GIL управляет потоками. Вот как это выглядит в случае использования двух потоков, интенсивно нагружающих процессов.\n\n![](https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/post_images\/f9e\/379\/f47\/f9e379f4724ba48881f53b489ca5ed1d.png)\n\n*Визуализация работы GIL (взято [отсюда](http:\/\/dabeaz.blogspot.com\/2010\/01\/python-gil-visualized.html))*\n\nЕсли у вас имеется веб-приложение (например, основанное на фреймворке Django), и вы используете WSGI, то каждый запрос к веб-приложению будет обслуживаться отдельным процессом интерпретатора Python, то есть, у нас имеется лишь 1 блокировка на запрос. Так как интерпретатор Python запускается медленно, в некоторых реализациях WSGI имеется так называемый «режим демона», при использовании которого [процессы интерпретатора](https:\/\/www.slideshare.net\/GrahamDumpleton\/secrets-of-a-wsgi-master) поддерживаются в рабочем состоянии, что позволяет системе быстрее обслуживать запросы.\n\n### ▍Как ведут себя другие интерпретаторы Python?\nВ [PyPy](http:\/\/doc.pypy.org\/en\/latest\/faq.html#does-pypy-have-a-gil-why) есть GIL, он обычно более чем в 3 раза быстрее, чем CPython.\n\nВ [Jython](http:\/\/www.jython.org\/jythonbook\/en\/1.0\/Concurrency.html#no-global-interpreter-lock) нет GIL, так как потоки Python в Jython представлены в виде потоков Java. Такие потоки используют возможности по управлению памятью JVM.\n\n### ▍Как управление потоками организовано в JavaScript?\nЕсли говорить о JavaScript, то, в первую очередь, надо отметить, что все JS-движки используют алгоритм сборки мусора [mark-and-sweep](https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/JavaScript\/Memory_Management). Как уже было сказано, основная причина необходимости использования GIL — это алгоритм управления памятью, применяемый в CPython.\n\nВ JavaScript нет GIL, однако, JS — это однопоточный язык, поэтому в нём подобный механизм и не нужен. Вместо параллельного выполнения кода в JavaScript применяются методики асинхронного программирования, основанные на цикле событий, промисах и коллбэках. В Python есть нечто подобное, представленное модулем `asyncio`.\n\n## Python — интерпретируемый язык\nМне часто приходилось слышать о том, что низкая производительность Python является следствием того, что это — интерпретируемый язык. Подобные утверждения основаны на грубом упрощении того, как, на самом деле, работает CPython. Если, в терминале, ввести команду вроде `python myscript.py`, тогда CPython начнёт длительную последовательность действий, которая заключается в чтении, лексическом анализе, парсинге, компиляции, интерпретации и выполнении кода скрипта. Если вас интересуют подробности — взгляните на [этот](https:\/\/hackernoon.com\/modifying-the-python-language-in-7-minutes-b94b0a99ce14) материал.\n\nДля нас, при рассмотрении этого процесса, особенно важным является тот факт, что здесь, на стадии компиляции, создаётся `.pyc`\\-файл, и последовательность байт-кодов пишется в файл в директории `__pycache__\/`, которая используется и в Python 3, и в Python 2.\n\nПодобное применяется не только к написанным нами скриптам, но и к импортированному коду, включая сторонние модули.\n\nВ результате, большую часть времени (если только вы не пишете код, который запускается лишь один раз) Python занимается выполнением готового байт-кода. Если сравнить это с тем, что происходит в Java и в C\\#, окажется, что код на Java компилируется в «Intermediate Language», и виртуальная машина Java читает байт-код и выполняет его JIT-компиляцию в машинный код. «Промежуточный язык» .NET CIL (это то же самое, что .NET Common-Language-Runtime, CLR), использует JIT-компиляцию для перехода к машинному коду.\n\nВ результате, и в Java и в C\\# используется некий «промежуточный язык» и присутствуют похожие механизмы. Почему же тогда Python показывает в бенчмарках гораздо худшие результаты, чем Java и C\\#, если все эти языки используют виртуальные машины и какие-то разновидности байт-кода? В первую очередь — из-за того, что в .NET и в Java используется JIT-компиляция.\n\nJIT-компиляция (Just In Time compilation, компиляция «на лету» или «точно в срок») требует наличия промежуточного языка для того, чтобы позволить осуществлять разбиение кода на фрагменты (кадры). Системы AOT-компиляции (Ahead Of Time compilation, компиляция перед исполнением) спроектированы так, чтобы обеспечить полную работоспособность кода до того, как начнётся взаимодействие этого кода с системой.\n\nСамо по себе использование JIT не ускоряет выполнение кода, так как на выполнение поступают, как и в Python, некие фрагменты байт-кода. Однако JIT позволяет выполнять оптимизации кода в процессе его выполнения. Хороший JIT-оптимизатор способен выявить наиболее нагруженные части приложения (такую часть приложения называют «hot spot») и оптимизировать соответствующие фрагменты кода, заменив их оптимизированными и более производительными вариантами, чем те, что использовались ранее.\n\nЭто означает, что когда некое приложение снова и снова выполняет некие действия, подобная оптимизация способна значительно ускорить выполнение таких действий. Кроме того, не забывайте о том, что Java и C\\# — это языки со строгой типизацией, поэтому оптимизатор может делать о коде больше предположений, способствующих улучшению производительности программ.\n\nJIT-компилятор есть в PyPy, и, как уже было сказано, эта реализация интерпретатора Python гораздо быстрее, чем CPython. Сведения, касающиеся сравнения разных интерпретаторов Python, можно найти в [этом](https:\/\/hackernoon.com\/which-is-the-fastest-version-of-python-2ae7c61a6b2b) материале.\n\n### ▍Почему в CPython не используется JIT-компилятор?\nУ JIT-компиляторов есть и недостатки. Один из них — время запуска. CPython и так запускается сравнительно медленно, а PyPy в 2-3 раза медленнее, чем CPython. Длительное время запуска JVM — это тоже известный факт. CLR .NET обходит эту проблему, запускаясь в ходе загрузки системы, но тут надо отметить, что и CLR, и та операционная система, в которой запускается CLR, разрабатываются одной и той же компанией.\n\nЕсли у вас имеется один процесс Python, который работает длительное время, при этом в таком процессе имеется код, который может быть оптимизирован, так как он содержит интенсивно используемые участки, тогда вам стоит серьёзно взглянуть на интерпретатор, имеющий JIT-компилятор.\n\nОднако, CPython — это реализация интерпретатора Python общего назначения. Поэтому, если вы разрабатываете, с использованием Python, приложения командной строки, то необходимость длительного ожидания запуска JIT-компилятора при каждом запуске этого приложения сильно замедлит работу.\n\nCPython пытается обеспечить поддержку как можно большего количества вариантов использования Python. Например, существует возможности подключения JIT-компилятора к Python, правда, [проект](https:\/\/www.slideshare.net\/AnthonyShaw5\/pyjion-a-jit-extension-system-for-cpython), в рамках которого реализуется эта идея, развивается не особенно активно.\n\nВ результате можно сказать, что если вы, с помощью Python, пишете программу, производительность которой может улучшиться при использовании JIT-компилятора — используйте интерпретатор PyPy.\n\n## Python — динамически типизированный язык\nВ статически типизированных языках, при объявлении переменных, необходимо указывать их типы. Среди таких языков можно отметить C, C++, Java, C\\#, Go.\n\nВ динамически типизированных языках понятие типа данных имеет тот же смысл, но тип переменной является динамическим.\n```\na = 1\na = \"foo\"\n```\nВ этом простейшем примере Python сначала создаёт первую переменную `a`, потом — вторую с тем же именем, имеющую тип `str`, и освобождает память, которая была выделена первой переменной `a`.\n\nМожет показаться, что писать на языках с динамической типизацией удобнее и проще, чем на языках со статической типизацией, однако, такие языки созданы не по чьей-то прихоти. При их разработке учтены особенности работы компьютерных систем. Всё, что написано в тексте программы, в итоге, сводится к инструкциям процессора. Это означает, что данные, используемые программой, например, в виде объектов или других типов данных, тоже преобразуются к низкоуровневым структурам.\n\nPython выполняет подобные преобразования автоматически, программист этих процессов не видит, и заботиться о подобных преобразованиях ему не нужно.\n\nОтсутствие необходимости указывать тип переменной при её объявлении — это не та особенность языка, которая делает Python медленным. Архитектура языка позволяет сделать динамическим практически всё, что угодно. Например, во время выполнения программы можно заменять методы объектов. Опять же, во время выполнения программы можно использовать технику «обезьяньих патчей» в применении к низкоуровневым системным вызовам. В Python возможно практически всё.\n\nИменно архитектура Python чрезвычайно усложняет оптимизацию.\n\nДля того чтобы проиллюстрировать эту идею, я собираюсь воспользоваться инструментом для трассировки системных вызовов в MacOS, который называется DTrace.\n\nВ готовом дистрибутиве CPython нет механизмов поддержки DTrace, поэтому CPython нужно будет перекомпилировать с соответствующими настройками. Тут используется версия 3.6.6. Итак, воспользуемся следующей последовательностью действий:\n```\nwget https:\/\/github.com\/python\/cpython\/archive\/v3.6.6.zip\nunzip v3.6.6.zip\ncd v3.6.6\n.\/configure --with-dtrace\nmake\n```\nТеперь, пользуясь `python.exe`, можно применять DTRace для трассировки кода. Об использовании DTrace с Python можно почитать [здесь](https:\/\/github.com\/paulross\/dtrace-py#the-lightning-talk). А вот [тут](https:\/\/github.com\/paulross\/dtrace-py\/tree\/master\/toolkit) можно найти скрипты для измерения с помощью DTrace различных показателей работы Python-программ. Среди них — параметры вызова функций, время выполнения программ, время использования процессора, сведения о системных вызовах и так далее. Вот как пользоваться командой `dtrace`:\n```\nsudo dtrace -s toolkit\/<tracer>.d -c ‘..\/cpython\/python.exe script.py’\n```\nА вот как средство трассировки `py_callflow` показывает вызовы функций в приложении.\n\n![](https:\/\/habrastorage.org\/getpro\/habr\/post_images\/13e\/bd4\/926\/13ebd492636a94b23400305293aec346.gif)\n\n*Трассировка с использованием DTrace*\n\nТеперь ответим на вопрос о том, влияет ли динамическая типизация на производительность Python. Вот некоторые соображения по этому поводу:\n\n- Проверка и конверсия типов — операции тяжёлые. Каждый раз, когда выполняется обращение к переменной, её чтение или запись, производится проверка типа.\n- Язык, обладающей подобной гибкостью, сложно оптимизировать. Причина, по которой другие языки настолько быстрее Python, заключается в том, что они идут на те или иные компромиссы, выбирая между гибкостью и производительностью.\n- Проект [Cython](http:\/\/cython.org\/) объединяет Python и статическую типизацию, что, например, как показано в [этом материале](http:\/\/notes-on-cython.readthedocs.io\/en\/latest\/std_dev.html), приводит к 84-кратному росту производительности в сравнении с применением обычного Python. Обратите внимание на этот проект, если вам нужна скорость.\n## Итоги\nПричиной невысокой производительности Python является его динамическая природа и универсальность. Его можно использовать как инструмент для решения разнообразнейших задач. Для достижения тех же целей можно попытаться поискать более производительные, лучше оптимизированные инструменты. Возможно, найти их удастся, возможно — нет.\n\nПриложения, написанные на Python, можно оптимизировать, используя возможности по асинхронному выполнению кода, инструменты профилирования, и — правильно подбирая интерпретатор. Так, для оптимизации скорости работы приложений, время запуска которых неважно, а производительность которых может выиграть от использования JIT-компилятора, рассмотрите возможность использования PyPy. Если вам нужна максимальная производительность и вы готовы к ограничениям статической типизации — взгляните на Cython.\n\n**Уважаемые читатели\\!** Как вы решаете проблемы невысокой производительности Python?\n\n[![](https:\/\/habrastorage.org\/r\/w1560\/files\/1ba\/550\/d25\/1ba550d25e8846ce8805de564da6aa63.png)](https:\/\/ruvds.com\/ru-rub\/#order)","meta_canonical":null}

3. Robots.txt Check

Query:

Response:

4. Spam/Ban Check

Query:

Response:

5. Seen Status Check

ℹ️ Skipped - page is already crawled

📄

INDEXABLE

✅

CRAWLED

2 months ago

🤖

ROBOTS ALLOWED

Page Info Filters

Filter	Status	Condition	Details
HTTP status	PASS	`download_http_code = 200`	HTTP 200
Age cutoff	PASS	`download_stamp > now() - 6 MONTH`	2.3 months ago
History drop	PASS	`isNull(history_drop_reason)`	No drop reason
Spam/ban	PASS	`fh_dont_index != 1 AND ml_spam_score = 0`	ml_spam_score=0
Canonical	PASS	`meta_canonical IS NULL OR = '' OR = src_unparsed`	Not set

Page Details

Property	Value
URL	https://habr.com/ru/companies/ruvds/articles/418823/
Last Crawled	2026-02-10 23:21:42 (2 months ago)
First Indexed	2023-05-06 09:39:24 (2 years ago)
HTTP Status Code	200
Meta Title	Python — это медленно. Почему? / Хабр
Meta Description	В последнее время можно наблюдать рост популярности языка программирования Python. Он используется в DevOps, в анализе данных, в веб-разработке, в сфере безопасности и в других областях. Но вот...
Meta Canonical	null
Boilerpipe Text	Время на прочтение 9 мин Охват и читатели 92K Перевод В последнее время можно наблюдать рост популярности языка программирования Python. Он используется в DevOps, в анализе данных, в веб-разработке, в сфере безопасности и в других областях. Но вот скорость… Здесь этому языку похвастаться нечем. Автор материала, перевод которого мы сегодня публикуем, решил выяснить причины медлительности Python и найти средства его ускорения. Общие положения Как Java, в плане производительности, соотносится с C или C++? Как сравнить C# и Python? Ответы на эти вопросы серьёзно зависят от типа анализируемых исследователем приложений. Не существует идеального бенчмарка, но, изучая производительность программ, написанных на разных языках, неплохой отправной точкой может стать проект The Computer Language Benchmarks Game. Я ссылаюсь на The Computer Language Benchmarks Game уже больше десяти лет. Python, в сравнении с другими языками, такими, как Java, C#, Go, JavaScript, C++, является одним из самых медленных . Сюда входят языки, в которых используется JIT -компиляция (C#, Java), и AOT -компиляция (C, C++), а также интерпретируемые языки, такие, как JavaScript. Тут мне хотелось бы отметить, что говоря «Python», я имею в виду эталонную реализацию интерпретатора Python — CPython. В этом материале мы коснёмся и других его реализаций. Собственно говоря, здесь мне хочется найти ответ на вопрос о том, почему Python требуется в 2-10 раз больше времени, чем другим языкам, на решение сопоставимых задач, и о том, можно ли сделать его быстрее. Вот основные теории, пытающиеся объяснить причины медленной работы Python: Причина этого — в GIL (Global Interpreter Lock, глобальная блокировка интерпретатора). Причина в том, что Python — это интерпретируемый, а не компилируемый язык. Причина — в динамической типизации. Проанализируем эти идеи и попытаемся найти ответ на вопрос о том, что сильнее всего оказывает влияние на производительность Python-приложений. GIL Современные компьютеры обладают многоядерными процессорами, иногда встречаются и многопроцессорные системы. Для того чтобы использовать всю эту вычислительную мощь, операционная система применяет низкоуровневые структуры, называемые потоками, в то время как процессы (например — процесс браузера Chrome) могут запускать множество потоков и соответствующим образом их использовать. В результате, например, если какой-то процесс особенно сильно нуждается в ресурсах процессора, его выполнение может быть разделено между несколькими ядрами, что позволяет большинству приложений быстрее решать встающие перед ними задачи. Например, у моего браузера Chrome, в тот момент, когда я это пишу, имеется 44 открытых потока. Тут стоит учитывать то, что структура и API системы работы с потоками различается в операционных системах, основанных на Posix (Mac OS, Linux), и в ОС семейства Windows. Операционная система, кроме того, занимается планированием работы потоков. Если раньше вы не встречались с многопоточным программированием, то сейчас вам нужно познакомиться с так называемыми блокировками (locks). Смысл блокировок заключается в том, что они позволяют обеспечить такое поведение системы, когда, в многопоточной среде, например, при изменении некоей переменной в памяти, доступ к одной и той же области памяти (для чтения или изменения) не могут одновременно получить несколько потоков. Когда интерпретатор CPython создаёт переменные, он выделяет память, а затем подсчитывает количество существующих ссылок на эти переменные. Эта концепция известна как подсчёт ссылок (reference counting). Если число ссылок равняется нулю, тогда соответствующий участок памяти освобождается. Именно поэтому, например, создание «временных» переменных, скажем, в пределах областей видимости циклов, не приводит к чрезмерному увеличению объёма памяти, потребляемого приложением. Самое интересное начинается тогда, когда одними и теми же переменными совместно пользуются несколько потоков, а главная проблема тут заключается в том, как именно CPython выполняет подсчёт ссылок. Тут и проявляется действие «глобальной блокировки интерпретатора», которая тщательно контролирует выполнение потоков. Интерпретатор может выполнять лишь одну операцию за раз, независимо от того, как много потоков имеется в программе. ▍Как GIL влияет на производительность Python-приложений? Если у нас имеется однопоточное приложение, работающее в одном процессе интерпретатора Python, то GIL никак на производительность не влияет. Если, например, избавиться от GIL, никакой разницы в производительности мы не заметим. Если же, в пределах одного процесса интерпретатора Python, надо реализовать параллельную обработку данных с применением механизмов многопоточности, и используемые потоки будут интенсивно использовать подсистему ввода-вывода (например, если они будут работать с сетью или с диском), тогда можно будет наблюдать последствия того, как GIL управляет потоками. Вот как это выглядит в случае использования двух потоков, интенсивно нагружающих процессов. Визуализация работы GIL (взято отсюда ) Если у вас имеется веб-приложение (например, основанное на фреймворке Django), и вы используете WSGI, то каждый запрос к веб-приложению будет обслуживаться отдельным процессом интерпретатора Python, то есть, у нас имеется лишь 1 блокировка на запрос. Так как интерпретатор Python запускается медленно, в некоторых реализациях WSGI имеется так называемый «режим демона», при использовании которого процессы интерпретатора поддерживаются в рабочем состоянии, что позволяет системе быстрее обслуживать запросы. ▍Как ведут себя другие интерпретаторы Python? В PyPy есть GIL, он обычно более чем в 3 раза быстрее, чем CPython. В Jython нет GIL, так как потоки Python в Jython представлены в виде потоков Java. Такие потоки используют возможности по управлению памятью JVM. ▍Как управление потоками организовано в JavaScript? Если говорить о JavaScript, то, в первую очередь, надо отметить, что все JS-движки используют алгоритм сборки мусора mark-and-sweep . Как уже было сказано, основная причина необходимости использования GIL — это алгоритм управления памятью, применяемый в CPython. В JavaScript нет GIL, однако, JS — это однопоточный язык, поэтому в нём подобный механизм и не нужен. Вместо параллельного выполнения кода в JavaScript применяются методики асинхронного программирования, основанные на цикле событий, промисах и коллбэках. В Python есть нечто подобное, представленное модулем asyncio . Python — интерпретируемый язык Мне часто приходилось слышать о том, что низкая производительность Python является следствием того, что это — интерпретируемый язык. Подобные утверждения основаны на грубом упрощении того, как, на самом деле, работает CPython. Если, в терминале, ввести команду вроде python myscript.py , тогда CPython начнёт длительную последовательность действий, которая заключается в чтении, лексическом анализе, парсинге, компиляции, интерпретации и выполнении кода скрипта. Если вас интересуют подробности — взгляните на этот материал. Для нас, при рассмотрении этого процесса, особенно важным является тот факт, что здесь, на стадии компиляции, создаётся .pyc -файл, и последовательность байт-кодов пишется в файл в директории __pycache__/ , которая используется и в Python 3, и в Python 2. Подобное применяется не только к написанным нами скриптам, но и к импортированному коду, включая сторонние модули. В результате, большую часть времени (если только вы не пишете код, который запускается лишь один раз) Python занимается выполнением готового байт-кода. Если сравнить это с тем, что происходит в Java и в C#, окажется, что код на Java компилируется в «Intermediate Language», и виртуальная машина Java читает байт-код и выполняет его JIT-компиляцию в машинный код. «Промежуточный язык» .NET CIL (это то же самое, что .NET Common-Language-Runtime, CLR), использует JIT-компиляцию для перехода к машинному коду. В результате, и в Java и в C# используется некий «промежуточный язык» и присутствуют похожие механизмы. Почему же тогда Python показывает в бенчмарках гораздо худшие результаты, чем Java и C#, если все эти языки используют виртуальные машины и какие-то разновидности байт-кода? В первую очередь — из-за того, что в .NET и в Java используется JIT-компиляция. JIT-компиляция (Just In Time compilation, компиляция «на лету» или «точно в срок») требует наличия промежуточного языка для того, чтобы позволить осуществлять разбиение кода на фрагменты (кадры). Системы AOT-компиляции (Ahead Of Time compilation, компиляция перед исполнением) спроектированы так, чтобы обеспечить полную работоспособность кода до того, как начнётся взаимодействие этого кода с системой. Само по себе использование JIT не ускоряет выполнение кода, так как на выполнение поступают, как и в Python, некие фрагменты байт-кода. Однако JIT позволяет выполнять оптимизации кода в процессе его выполнения. Хороший JIT-оптимизатор способен выявить наиболее нагруженные части приложения (такую часть приложения называют «hot spot») и оптимизировать соответствующие фрагменты кода, заменив их оптимизированными и более производительными вариантами, чем те, что использовались ранее. Это означает, что когда некое приложение снова и снова выполняет некие действия, подобная оптимизация способна значительно ускорить выполнение таких действий. Кроме того, не забывайте о том, что Java и C# — это языки со строгой типизацией, поэтому оптимизатор может делать о коде больше предположений, способствующих улучшению производительности программ. JIT-компилятор есть в PyPy, и, как уже было сказано, эта реализация интерпретатора Python гораздо быстрее, чем CPython. Сведения, касающиеся сравнения разных интерпретаторов Python, можно найти в этом материале. ▍Почему в CPython не используется JIT-компилятор? У JIT-компиляторов есть и недостатки. Один из них — время запуска. CPython и так запускается сравнительно медленно, а PyPy в 2-3 раза медленнее, чем CPython. Длительное время запуска JVM — это тоже известный факт. CLR .NET обходит эту проблему, запускаясь в ходе загрузки системы, но тут надо отметить, что и CLR, и та операционная система, в которой запускается CLR, разрабатываются одной и той же компанией. Если у вас имеется один процесс Python, который работает длительное время, при этом в таком процессе имеется код, который может быть оптимизирован, так как он содержит интенсивно используемые участки, тогда вам стоит серьёзно взглянуть на интерпретатор, имеющий JIT-компилятор. Однако, CPython — это реализация интерпретатора Python общего назначения. Поэтому, если вы разрабатываете, с использованием Python, приложения командной строки, то необходимость длительного ожидания запуска JIT-компилятора при каждом запуске этого приложения сильно замедлит работу. CPython пытается обеспечить поддержку как можно большего количества вариантов использования Python. Например, существует возможности подключения JIT-компилятора к Python, правда, проект , в рамках которого реализуется эта идея, развивается не особенно активно. В результате можно сказать, что если вы, с помощью Python, пишете программу, производительность которой может улучшиться при использовании JIT-компилятора — используйте интерпретатор PyPy. Python — динамически типизированный язык В статически типизированных языках, при объявлении переменных, необходимо указывать их типы. Среди таких языков можно отметить C, C++, Java, C#, Go. В динамически типизированных языках понятие типа данных имеет тот же смысл, но тип переменной является динамическим. a = 1 a = "foo" В этом простейшем примере Python сначала создаёт первую переменную a , потом — вторую с тем же именем, имеющую тип str , и освобождает память, которая была выделена первой переменной a . Может показаться, что писать на языках с динамической типизацией удобнее и проще, чем на языках со статической типизацией, однако, такие языки созданы не по чьей-то прихоти. При их разработке учтены особенности работы компьютерных систем. Всё, что написано в тексте программы, в итоге, сводится к инструкциям процессора. Это означает, что данные, используемые программой, например, в виде объектов или других типов данных, тоже преобразуются к низкоуровневым структурам. Python выполняет подобные преобразования автоматически, программист этих процессов не видит, и заботиться о подобных преобразованиях ему не нужно. Отсутствие необходимости указывать тип переменной при её объявлении — это не та особенность языка, которая делает Python медленным. Архитектура языка позволяет сделать динамическим практически всё, что угодно. Например, во время выполнения программы можно заменять методы объектов. Опять же, во время выполнения программы можно использовать технику «обезьяньих патчей» в применении к низкоуровневым системным вызовам. В Python возможно практически всё. Именно архитектура Python чрезвычайно усложняет оптимизацию. Для того чтобы проиллюстрировать эту идею, я собираюсь воспользоваться инструментом для трассировки системных вызовов в MacOS, который называется DTrace. В готовом дистрибутиве CPython нет механизмов поддержки DTrace, поэтому CPython нужно будет перекомпилировать с соответствующими настройками. Тут используется версия 3.6.6. Итак, воспользуемся следующей последовательностью действий: wget https://github.com/python/cpython/archive/v3.6.6.zip unzip v3.6.6.zip cd v3.6.6 ./configure --with-dtrace make Теперь, пользуясь python.exe , можно применять DTRace для трассировки кода. Об использовании DTrace с Python можно почитать здесь . А вот тут можно найти скрипты для измерения с помощью DTrace различных показателей работы Python-программ. Среди них — параметры вызова функций, время выполнения программ, время использования процессора, сведения о системных вызовах и так далее. Вот как пользоваться командой dtrace : sudo dtrace -s toolkit/<tracer>.d -c ‘../cpython/python.exe script.py’ А вот как средство трассировки py_callflow показывает вызовы функций в приложении. Трассировка с использованием DTrace Теперь ответим на вопрос о том, влияет ли динамическая типизация на производительность Python. Вот некоторые соображения по этому поводу: Проверка и конверсия типов — операции тяжёлые. Каждый раз, когда выполняется обращение к переменной, её чтение или запись, производится проверка типа. Язык, обладающей подобной гибкостью, сложно оптимизировать. Причина, по которой другие языки настолько быстрее Python, заключается в том, что они идут на те или иные компромиссы, выбирая между гибкостью и производительностью. Проект Cython объединяет Python и статическую типизацию, что, например, как показано в этом материале , приводит к 84-кратному росту производительности в сравнении с применением обычного Python. Обратите внимание на этот проект, если вам нужна скорость. Итоги Причиной невысокой производительности Python является его динамическая природа и универсальность. Его можно использовать как инструмент для решения разнообразнейших задач. Для достижения тех же целей можно попытаться поискать более производительные, лучше оптимизированные инструменты. Возможно, найти их удастся, возможно — нет. Приложения, написанные на Python, можно оптимизировать, используя возможности по асинхронному выполнению кода, инструменты профилирования, и — правильно подбирая интерпретатор. Так, для оптимизации скорости работы приложений, время запуска которых неважно, а производительность которых может выиграть от использования JIT-компилятора, рассмотрите возможность использования PyPy. Если вам нужна максимальная производительность и вы готовы к ограничениям статической типизации — взгляните на Cython. Уважаемые читатели! Как вы решаете проблемы невысокой производительности Python?
Markdown	[Все потоки](https://habr.com/ru/articles/) [Войти](https://habr.com/kek/v1/auth/habrahabr/?back=/ru/companies/ruvds/articles/418823/&hl=ru) [![](https://habrastorage.org/getpro/habr/branding/937/973/199/9379731999358877e1a6e6fa2423bcc8.png)](https://ruvds.com/ru-rub?utm_source=habr&utm_medium=banner&utm_campaign=promo&utm_content=link&?erid=LjN8KAR3S) [![](https://habrastorage.org/getpro/habr/company/608/f02/206/608f0220675e20da793aa1974a1a0a2e.png)](https://habr.com/ru/companies/ruvds/profile/) 3301\.3 Общий рейтинг [RUVDS.com](https://habr.com/ru/companies/ruvds/profile/) VDS/VPS-хостинг. Скидка 15% по коду HABR15 Подписаться [![](https://habrastorage.org/r/w48/getpro/habr/avatars/1b8/7ff/39c/1b87ff39ce6dfc7224cb45ab05384ecc.png)](https://habr.com/ru/users/ru_vds/) [ru\_vds](https://habr.com/ru/users/ru_vds/) 1 авг 2018 в 09:26 # Python — это медленно. Почему? 9 мин 92K [Блог компании RUVDS.com](https://habr.com/ru/companies/ruvds/articles/)[Python \](https://habr.com/ru/hubs/python/) [Веб-разработка \](https://habr.com/ru/hubs/webdev/) Перевод [Автор оригинала: Anthony Shaw](https://hackernoon.com/why-is-python-so-slow-e5074b6fe55b) В последнее время можно наблюдать рост популярности языка программирования Python. Он используется в DevOps, в анализе данных, в веб-разработке, в сфере безопасности и в других областях. Но вот скорость… Здесь этому языку похвастаться нечем. Автор материала, перевод которого мы сегодня публикуем, решил выяснить причины медлительности Python и найти средства его ускорения. [![](https://habrastorage.org/r/w1560/webt/tv/zp/uz/tvzpuzzfhsgdyegpe8ri3pbl3mw.jpeg)](https://habr.com/company/ruvds/blog/418823/) ## Общие положения Как Java, в плане производительности, соотносится с C или C++? Как сравнить C\# и Python? Ответы на эти вопросы серьёзно зависят от типа анализируемых исследователем приложений. Не существует идеального бенчмарка, но, изучая производительность программ, написанных на разных языках, неплохой [отправной точкой](http://algs4.cs.princeton.edu/faq/) может стать проект The Computer Language Benchmarks Game. Я ссылаюсь на The Computer Language Benchmarks Game уже больше десяти лет. Python, в сравнении с другими языками, такими, как Java, C\#, Go, JavaScript, C++, является одним из [самых медленных](https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/python.html). Сюда входят языки, в которых используется [JIT](https://en.wikipedia.org/wiki/Just-in-time_compilation)\-компиляция (C\#, Java), и [AOT](https://en.wikipedia.org/wiki/Ahead-of-time_compilation)\-компиляция (C, C++), а также интерпретируемые языки, такие, как JavaScript. Тут мне хотелось бы отметить, что говоря «Python», я имею в виду эталонную реализацию интерпретатора Python — CPython. В этом материале мы коснёмся и других его реализаций. Собственно говоря, здесь мне хочется найти ответ на вопрос о том, почему Python требуется в 2-10 раз больше времени, чем другим языкам, на решение сопоставимых задач, и о том, можно ли сделать его быстрее. Вот основные теории, пытающиеся объяснить причины медленной работы Python: - Причина этого — в GIL (Global Interpreter Lock, глобальная блокировка интерпретатора). - Причина в том, что Python — это интерпретируемый, а не компилируемый язык. - Причина — в динамической типизации. Проанализируем эти идеи и попытаемся найти ответ на вопрос о том, что сильнее всего оказывает влияние на производительность Python-приложений. ## GIL Современные компьютеры обладают многоядерными процессорами, иногда встречаются и многопроцессорные системы. Для того чтобы использовать всю эту вычислительную мощь, операционная система применяет низкоуровневые структуры, называемые потоками, в то время как процессы (например — процесс браузера Chrome) могут запускать множество потоков и соответствующим образом их использовать. В результате, например, если какой-то процесс особенно сильно нуждается в ресурсах процессора, его выполнение может быть разделено между несколькими ядрами, что позволяет большинству приложений быстрее решать встающие перед ними задачи. Например, у моего браузера Chrome, в тот момент, когда я это пишу, имеется 44 открытых потока. Тут стоит учитывать то, что структура и API системы работы с потоками различается в операционных системах, основанных на Posix (Mac OS, Linux), и в ОС семейства Windows. Операционная система, кроме того, занимается планированием работы потоков. Если раньше вы не встречались с многопоточным программированием, то сейчас вам нужно познакомиться с так называемыми блокировками (locks). Смысл блокировок заключается в том, что они позволяют обеспечить такое поведение системы, когда, в многопоточной среде, например, при изменении некоей переменной в памяти, доступ к одной и той же области памяти (для чтения или изменения) не могут одновременно получить несколько потоков. Когда интерпретатор CPython создаёт переменные, он выделяет память, а затем подсчитывает количество существующих ссылок на эти переменные. Эта концепция известна как подсчёт ссылок (reference counting). Если число ссылок равняется нулю, тогда соответствующий участок памяти освобождается. Именно поэтому, например, создание «временных» переменных, скажем, в пределах областей видимости циклов, не приводит к чрезмерному увеличению объёма памяти, потребляемого приложением. Самое интересное начинается тогда, когда одними и теми же переменными совместно пользуются несколько потоков, а главная проблема тут заключается в том, как именно CPython выполняет подсчёт ссылок. Тут и проявляется действие «глобальной блокировки интерпретатора», которая тщательно контролирует выполнение потоков. Интерпретатор может выполнять лишь одну операцию за раз, независимо от того, как много потоков имеется в программе. ### ▍Как GIL влияет на производительность Python-приложений? Если у нас имеется однопоточное приложение, работающее в одном процессе интерпретатора Python, то GIL никак на производительность не влияет. Если, например, избавиться от GIL, никакой разницы в производительности мы не заметим. Если же, в пределах одного процесса интерпретатора Python, надо реализовать параллельную обработку данных с применением механизмов многопоточности, и используемые потоки будут интенсивно использовать подсистему ввода-вывода (например, если они будут работать с сетью или с диском), тогда можно будет наблюдать последствия того, как GIL управляет потоками. Вот как это выглядит в случае использования двух потоков, интенсивно нагружающих процессов. ![](https://habrastorage.org/r/w1560/getpro/habr/post_images/f9e/379/f47/f9e379f4724ba48881f53b489ca5ed1d.png) Визуализация работы GIL (взято [отсюда](http://dabeaz.blogspot.com/2010/01/python-gil-visualized.html)) Если у вас имеется веб-приложение (например, основанное на фреймворке Django), и вы используете WSGI, то каждый запрос к веб-приложению будет обслуживаться отдельным процессом интерпретатора Python, то есть, у нас имеется лишь 1 блокировка на запрос. Так как интерпретатор Python запускается медленно, в некоторых реализациях WSGI имеется так называемый «режим демона», при использовании которого [процессы интерпретатора](https://www.slideshare.net/GrahamDumpleton/secrets-of-a-wsgi-master) поддерживаются в рабочем состоянии, что позволяет системе быстрее обслуживать запросы. ### ▍Как ведут себя другие интерпретаторы Python? В [PyPy](http://doc.pypy.org/en/latest/faq.html#does-pypy-have-a-gil-why) есть GIL, он обычно более чем в 3 раза быстрее, чем CPython. В [Jython](http://www.jython.org/jythonbook/en/1.0/Concurrency.html#no-global-interpreter-lock) нет GIL, так как потоки Python в Jython представлены в виде потоков Java. Такие потоки используют возможности по управлению памятью JVM. ### ▍Как управление потоками организовано в JavaScript? Если говорить о JavaScript, то, в первую очередь, надо отметить, что все JS-движки используют алгоритм сборки мусора [mark-and-sweep](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_Management). Как уже было сказано, основная причина необходимости использования GIL — это алгоритм управления памятью, применяемый в CPython. В JavaScript нет GIL, однако, JS — это однопоточный язык, поэтому в нём подобный механизм и не нужен. Вместо параллельного выполнения кода в JavaScript применяются методики асинхронного программирования, основанные на цикле событий, промисах и коллбэках. В Python есть нечто подобное, представленное модулем `asyncio`. ## Python — интерпретируемый язык Мне часто приходилось слышать о том, что низкая производительность Python является следствием того, что это — интерпретируемый язык. Подобные утверждения основаны на грубом упрощении того, как, на самом деле, работает CPython. Если, в терминале, ввести команду вроде `python myscript.py`, тогда CPython начнёт длительную последовательность действий, которая заключается в чтении, лексическом анализе, парсинге, компиляции, интерпретации и выполнении кода скрипта. Если вас интересуют подробности — взгляните на [этот](https://hackernoon.com/modifying-the-python-language-in-7-minutes-b94b0a99ce14) материал. Для нас, при рассмотрении этого процесса, особенно важным является тот факт, что здесь, на стадии компиляции, создаётся `.pyc`\-файл, и последовательность байт-кодов пишется в файл в директории `__pycache__/`, которая используется и в Python 3, и в Python 2. Подобное применяется не только к написанным нами скриптам, но и к импортированному коду, включая сторонние модули. В результате, большую часть времени (если только вы не пишете код, который запускается лишь один раз) Python занимается выполнением готового байт-кода. Если сравнить это с тем, что происходит в Java и в C\#, окажется, что код на Java компилируется в «Intermediate Language», и виртуальная машина Java читает байт-код и выполняет его JIT-компиляцию в машинный код. «Промежуточный язык» .NET CIL (это то же самое, что .NET Common-Language-Runtime, CLR), использует JIT-компиляцию для перехода к машинному коду. В результате, и в Java и в C\# используется некий «промежуточный язык» и присутствуют похожие механизмы. Почему же тогда Python показывает в бенчмарках гораздо худшие результаты, чем Java и C\#, если все эти языки используют виртуальные машины и какие-то разновидности байт-кода? В первую очередь — из-за того, что в .NET и в Java используется JIT-компиляция. JIT-компиляция (Just In Time compilation, компиляция «на лету» или «точно в срок») требует наличия промежуточного языка для того, чтобы позволить осуществлять разбиение кода на фрагменты (кадры). Системы AOT-компиляции (Ahead Of Time compilation, компиляция перед исполнением) спроектированы так, чтобы обеспечить полную работоспособность кода до того, как начнётся взаимодействие этого кода с системой. Само по себе использование JIT не ускоряет выполнение кода, так как на выполнение поступают, как и в Python, некие фрагменты байт-кода. Однако JIT позволяет выполнять оптимизации кода в процессе его выполнения. Хороший JIT-оптимизатор способен выявить наиболее нагруженные части приложения (такую часть приложения называют «hot spot») и оптимизировать соответствующие фрагменты кода, заменив их оптимизированными и более производительными вариантами, чем те, что использовались ранее. Это означает, что когда некое приложение снова и снова выполняет некие действия, подобная оптимизация способна значительно ускорить выполнение таких действий. Кроме того, не забывайте о том, что Java и C\# — это языки со строгой типизацией, поэтому оптимизатор может делать о коде больше предположений, способствующих улучшению производительности программ. JIT-компилятор есть в PyPy, и, как уже было сказано, эта реализация интерпретатора Python гораздо быстрее, чем CPython. Сведения, касающиеся сравнения разных интерпретаторов Python, можно найти в [этом](https://hackernoon.com/which-is-the-fastest-version-of-python-2ae7c61a6b2b) материале. ### ▍Почему в CPython не используется JIT-компилятор? У JIT-компиляторов есть и недостатки. Один из них — время запуска. CPython и так запускается сравнительно медленно, а PyPy в 2-3 раза медленнее, чем CPython. Длительное время запуска JVM — это тоже известный факт. CLR .NET обходит эту проблему, запускаясь в ходе загрузки системы, но тут надо отметить, что и CLR, и та операционная система, в которой запускается CLR, разрабатываются одной и той же компанией. Если у вас имеется один процесс Python, который работает длительное время, при этом в таком процессе имеется код, который может быть оптимизирован, так как он содержит интенсивно используемые участки, тогда вам стоит серьёзно взглянуть на интерпретатор, имеющий JIT-компилятор. Однако, CPython — это реализация интерпретатора Python общего назначения. Поэтому, если вы разрабатываете, с использованием Python, приложения командной строки, то необходимость длительного ожидания запуска JIT-компилятора при каждом запуске этого приложения сильно замедлит работу. CPython пытается обеспечить поддержку как можно большего количества вариантов использования Python. Например, существует возможности подключения JIT-компилятора к Python, правда, [проект](https://www.slideshare.net/AnthonyShaw5/pyjion-a-jit-extension-system-for-cpython), в рамках которого реализуется эта идея, развивается не особенно активно. В результате можно сказать, что если вы, с помощью Python, пишете программу, производительность которой может улучшиться при использовании JIT-компилятора — используйте интерпретатор PyPy. ## Python — динамически типизированный язык В статически типизированных языках, при объявлении переменных, необходимо указывать их типы. Среди таких языков можно отметить C, C++, Java, C\#, Go. В динамически типизированных языках понятие типа данных имеет тот же смысл, но тип переменной является динамическим. ``` ``` В этом простейшем примере Python сначала создаёт первую переменную `a`, потом — вторую с тем же именем, имеющую тип `str`, и освобождает память, которая была выделена первой переменной `a`. Может показаться, что писать на языках с динамической типизацией удобнее и проще, чем на языках со статической типизацией, однако, такие языки созданы не по чьей-то прихоти. При их разработке учтены особенности работы компьютерных систем. Всё, что написано в тексте программы, в итоге, сводится к инструкциям процессора. Это означает, что данные, используемые программой, например, в виде объектов или других типов данных, тоже преобразуются к низкоуровневым структурам. Python выполняет подобные преобразования автоматически, программист этих процессов не видит, и заботиться о подобных преобразованиях ему не нужно. Отсутствие необходимости указывать тип переменной при её объявлении — это не та особенность языка, которая делает Python медленным. Архитектура языка позволяет сделать динамическим практически всё, что угодно. Например, во время выполнения программы можно заменять методы объектов. Опять же, во время выполнения программы можно использовать технику «обезьяньих патчей» в применении к низкоуровневым системным вызовам. В Python возможно практически всё. Именно архитектура Python чрезвычайно усложняет оптимизацию. Для того чтобы проиллюстрировать эту идею, я собираюсь воспользоваться инструментом для трассировки системных вызовов в MacOS, который называется DTrace. В готовом дистрибутиве CPython нет механизмов поддержки DTrace, поэтому CPython нужно будет перекомпилировать с соответствующими настройками. Тут используется версия 3.6.6. Итак, воспользуемся следующей последовательностью действий: ``` ``` Теперь, пользуясь `python.exe`, можно применять DTRace для трассировки кода. Об использовании DTrace с Python можно почитать [здесь](https://github.com/paulross/dtrace-py#the-lightning-talk). А вот [тут](https://github.com/paulross/dtrace-py/tree/master/toolkit) можно найти скрипты для измерения с помощью DTrace различных показателей работы Python-программ. Среди них — параметры вызова функций, время выполнения программ, время использования процессора, сведения о системных вызовах и так далее. Вот как пользоваться командой `dtrace`: ``` sudo dtrace -s toolkit/<tracer>.d -c ‘../cpython/python.exe script.py’ ``` А вот как средство трассировки `py_callflow` показывает вызовы функций в приложении. ![](https://habrastorage.org/getpro/habr/post_images/13e/bd4/926/13ebd492636a94b23400305293aec346.gif) Трассировка с использованием DTrace Теперь ответим на вопрос о том, влияет ли динамическая типизация на производительность Python. Вот некоторые соображения по этому поводу: - Проверка и конверсия типов — операции тяжёлые. Каждый раз, когда выполняется обращение к переменной, её чтение или запись, производится проверка типа. - Язык, обладающей подобной гибкостью, сложно оптимизировать. Причина, по которой другие языки настолько быстрее Python, заключается в том, что они идут на те или иные компромиссы, выбирая между гибкостью и производительностью. - Проект [Cython](http://cython.org/) объединяет Python и статическую типизацию, что, например, как показано в [этом материале](http://notes-on-cython.readthedocs.io/en/latest/std_dev.html), приводит к 84-кратному росту производительности в сравнении с применением обычного Python. Обратите внимание на этот проект, если вам нужна скорость. ## Итоги Причиной невысокой производительности Python является его динамическая природа и универсальность. Его можно использовать как инструмент для решения разнообразнейших задач. Для достижения тех же целей можно попытаться поискать более производительные, лучше оптимизированные инструменты. Возможно, найти их удастся, возможно — нет. Приложения, написанные на Python, можно оптимизировать, используя возможности по асинхронному выполнению кода, инструменты профилирования, и — правильно подбирая интерпретатор. Так, для оптимизации скорости работы приложений, время запуска которых неважно, а производительность которых может выиграть от использования JIT-компилятора, рассмотрите возможность использования PyPy. Если вам нужна максимальная производительность и вы готовы к ограничениям статической типизации — взгляните на Cython. Уважаемые читатели\! Как вы решаете проблемы невысокой производительности Python? [![](https://habrastorage.org/r/w1560/files/1ba/550/d25/1ba550d25e8846ce8805de564da6aa63.png)](https://ruvds.com/ru-rub/#order) Теги: - [Python](https://habr.com/ru/search/?target_type=posts&order=relevance&q=[Python]) - [разработка](https://habr.com/ru/search/?target_type=posts&order=relevance&q=[%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0]) Хабы: - [Блог компании RUVDS.com](https://habr.com/ru/companies/ruvds/articles/) - [Python](https://habr.com/ru/hubs/python/) - [Веб-разработка](https://habr.com/ru/hubs/webdev/) \+48 253 [56](https://habr.com/ru/companies/ruvds/articles/418823/comments/) [![](https://habrastorage.org/getpro/habr/company/608/f02/206/608f0220675e20da793aa1974a1a0a2e.png)](https://habr.com/ru/companies/ruvds/profile/) [RUVDS.com](https://habr.com/ru/companies/ruvds/profile/) VDS/VPS-хостинг. Скидка 15% по коду HABR15 [Telegram](https://telegram.me/ruvds_community)[ВКонтакте](https://vk.com/ru_vds)[X](https://x.com/ru_vds) [![](https://habrastorage.org/getpro/habr/avatars/1b8/7ff/39c/1b87ff39ce6dfc7224cb45ab05384ecc.png)](https://habr.com/ru/users/ru_vds/) 610 Карма 27\.2 Общий рейтинг [@ru\_vds](https://habr.com/ru/users/ru_vds/) Пользователь Подписаться [Комментарии 56](https://habr.com/ru/companies/ruvds/articles/418823/comments/) ## Публикации Лучшие за сутки Похожие ## Информация Сайт [ruvds.com](https://ruvds.com/) Дата регистрации 18 марта 2016 Дата основания 27 июля 2015 Численность 11–30 человек Местоположение Россия Представитель [ruvds](https://habr.com/ru/users/ruvds/) Ваш аккаунт - [Войти](https://habr.com/kek/v1/auth/habrahabr/?back=/ru/companies/ruvds/articles/418823/&hl=ru) - [Регистрация](https://habr.com/kek/v1/auth/habrahabr-register/?back=/ru/companies/ruvds/articles/418823/&hl=ru) Разделы - [Статьи](https://habr.com/ru/articles/) - [Новости](https://habr.com/ru/news/) - [Хабы](https://habr.com/ru/hubs/) - [Компании](https://habr.com/ru/companies/) - [Авторы](https://habr.com/ru/users/) - [Песочница](https://habr.com/ru/sandbox/) Информация - [Устройство сайта](https://habr.com/ru/docs/help/) - [Для авторов](https://habr.com/ru/docs/authors/codex/) - [Для компаний](https://habr.com/ru/docs/companies/corpblogs/) - [Документы](https://habr.com/ru/docs/docs/transparency/) - [Соглашение](https://account.habr.com/info/agreement/?hl=ru_RU) - [Конфиденциальность](https://account.habr.com/info/confidential/?hl=ru_RU) Услуги - [Корпоративный блог](https://company.habr.com/ru/corporate-blogs/) - [Медийная реклама](https://company.habr.com/ru/advertising/) - [Нативные проекты](https://company.habr.com/ru/native-special/) - [Образовательные программы](https://company.habr.com/ru/education-programs/) - [Стартапам](https://company.habr.com/ru/hello-startup/) Настройка языка [Техническая поддержка](https://habr.com/ru/feedback/) © 2006–2026, [Habr](https://company.habr.com/)
Readable Markdown	9 мин 92K Перевод В последнее время можно наблюдать рост популярности языка программирования Python. Он используется в DevOps, в анализе данных, в веб-разработке, в сфере безопасности и в других областях. Но вот скорость… Здесь этому языку похвастаться нечем. Автор материала, перевод которого мы сегодня публикуем, решил выяснить причины медлительности Python и найти средства его ускорения. [![](https://habrastorage.org/r/w1560/webt/tv/zp/uz/tvzpuzzfhsgdyegpe8ri3pbl3mw.jpeg)](https://habr.com/company/ruvds/blog/418823/) ## Общие положения Как Java, в плане производительности, соотносится с C или C++? Как сравнить C\# и Python? Ответы на эти вопросы серьёзно зависят от типа анализируемых исследователем приложений. Не существует идеального бенчмарка, но, изучая производительность программ, написанных на разных языках, неплохой [отправной точкой](http://algs4.cs.princeton.edu/faq/) может стать проект The Computer Language Benchmarks Game. Я ссылаюсь на The Computer Language Benchmarks Game уже больше десяти лет. Python, в сравнении с другими языками, такими, как Java, C\#, Go, JavaScript, C++, является одним из [самых медленных](https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/python.html). Сюда входят языки, в которых используется [JIT](https://en.wikipedia.org/wiki/Just-in-time_compilation)\-компиляция (C\#, Java), и [AOT](https://en.wikipedia.org/wiki/Ahead-of-time_compilation)\-компиляция (C, C++), а также интерпретируемые языки, такие, как JavaScript. Тут мне хотелось бы отметить, что говоря «Python», я имею в виду эталонную реализацию интерпретатора Python — CPython. В этом материале мы коснёмся и других его реализаций. Собственно говоря, здесь мне хочется найти ответ на вопрос о том, почему Python требуется в 2-10 раз больше времени, чем другим языкам, на решение сопоставимых задач, и о том, можно ли сделать его быстрее. Вот основные теории, пытающиеся объяснить причины медленной работы Python: - Причина этого — в GIL (Global Interpreter Lock, глобальная блокировка интерпретатора). - Причина в том, что Python — это интерпретируемый, а не компилируемый язык. - Причина — в динамической типизации. Проанализируем эти идеи и попытаемся найти ответ на вопрос о том, что сильнее всего оказывает влияние на производительность Python-приложений. ## GIL Современные компьютеры обладают многоядерными процессорами, иногда встречаются и многопроцессорные системы. Для того чтобы использовать всю эту вычислительную мощь, операционная система применяет низкоуровневые структуры, называемые потоками, в то время как процессы (например — процесс браузера Chrome) могут запускать множество потоков и соответствующим образом их использовать. В результате, например, если какой-то процесс особенно сильно нуждается в ресурсах процессора, его выполнение может быть разделено между несколькими ядрами, что позволяет большинству приложений быстрее решать встающие перед ними задачи. Например, у моего браузера Chrome, в тот момент, когда я это пишу, имеется 44 открытых потока. Тут стоит учитывать то, что структура и API системы работы с потоками различается в операционных системах, основанных на Posix (Mac OS, Linux), и в ОС семейства Windows. Операционная система, кроме того, занимается планированием работы потоков. Если раньше вы не встречались с многопоточным программированием, то сейчас вам нужно познакомиться с так называемыми блокировками (locks). Смысл блокировок заключается в том, что они позволяют обеспечить такое поведение системы, когда, в многопоточной среде, например, при изменении некоей переменной в памяти, доступ к одной и той же области памяти (для чтения или изменения) не могут одновременно получить несколько потоков. Когда интерпретатор CPython создаёт переменные, он выделяет память, а затем подсчитывает количество существующих ссылок на эти переменные. Эта концепция известна как подсчёт ссылок (reference counting). Если число ссылок равняется нулю, тогда соответствующий участок памяти освобождается. Именно поэтому, например, создание «временных» переменных, скажем, в пределах областей видимости циклов, не приводит к чрезмерному увеличению объёма памяти, потребляемого приложением. Самое интересное начинается тогда, когда одними и теми же переменными совместно пользуются несколько потоков, а главная проблема тут заключается в том, как именно CPython выполняет подсчёт ссылок. Тут и проявляется действие «глобальной блокировки интерпретатора», которая тщательно контролирует выполнение потоков. Интерпретатор может выполнять лишь одну операцию за раз, независимо от того, как много потоков имеется в программе. ### ▍Как GIL влияет на производительность Python-приложений? Если у нас имеется однопоточное приложение, работающее в одном процессе интерпретатора Python, то GIL никак на производительность не влияет. Если, например, избавиться от GIL, никакой разницы в производительности мы не заметим. Если же, в пределах одного процесса интерпретатора Python, надо реализовать параллельную обработку данных с применением механизмов многопоточности, и используемые потоки будут интенсивно использовать подсистему ввода-вывода (например, если они будут работать с сетью или с диском), тогда можно будет наблюдать последствия того, как GIL управляет потоками. Вот как это выглядит в случае использования двух потоков, интенсивно нагружающих процессов. ![](https://habrastorage.org/r/w1560/getpro/habr/post_images/f9e/379/f47/f9e379f4724ba48881f53b489ca5ed1d.png) Визуализация работы GIL (взято [отсюда](http://dabeaz.blogspot.com/2010/01/python-gil-visualized.html)) Если у вас имеется веб-приложение (например, основанное на фреймворке Django), и вы используете WSGI, то каждый запрос к веб-приложению будет обслуживаться отдельным процессом интерпретатора Python, то есть, у нас имеется лишь 1 блокировка на запрос. Так как интерпретатор Python запускается медленно, в некоторых реализациях WSGI имеется так называемый «режим демона», при использовании которого [процессы интерпретатора](https://www.slideshare.net/GrahamDumpleton/secrets-of-a-wsgi-master) поддерживаются в рабочем состоянии, что позволяет системе быстрее обслуживать запросы. ### ▍Как ведут себя другие интерпретаторы Python? В [PyPy](http://doc.pypy.org/en/latest/faq.html#does-pypy-have-a-gil-why) есть GIL, он обычно более чем в 3 раза быстрее, чем CPython. В [Jython](http://www.jython.org/jythonbook/en/1.0/Concurrency.html#no-global-interpreter-lock) нет GIL, так как потоки Python в Jython представлены в виде потоков Java. Такие потоки используют возможности по управлению памятью JVM. ### ▍Как управление потоками организовано в JavaScript? Если говорить о JavaScript, то, в первую очередь, надо отметить, что все JS-движки используют алгоритм сборки мусора [mark-and-sweep](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_Management). Как уже было сказано, основная причина необходимости использования GIL — это алгоритм управления памятью, применяемый в CPython. В JavaScript нет GIL, однако, JS — это однопоточный язык, поэтому в нём подобный механизм и не нужен. Вместо параллельного выполнения кода в JavaScript применяются методики асинхронного программирования, основанные на цикле событий, промисах и коллбэках. В Python есть нечто подобное, представленное модулем `asyncio`. ## Python — интерпретируемый язык Мне часто приходилось слышать о том, что низкая производительность Python является следствием того, что это — интерпретируемый язык. Подобные утверждения основаны на грубом упрощении того, как, на самом деле, работает CPython. Если, в терминале, ввести команду вроде `python myscript.py`, тогда CPython начнёт длительную последовательность действий, которая заключается в чтении, лексическом анализе, парсинге, компиляции, интерпретации и выполнении кода скрипта. Если вас интересуют подробности — взгляните на [этот](https://hackernoon.com/modifying-the-python-language-in-7-minutes-b94b0a99ce14) материал. Для нас, при рассмотрении этого процесса, особенно важным является тот факт, что здесь, на стадии компиляции, создаётся `.pyc`\-файл, и последовательность байт-кодов пишется в файл в директории `__pycache__/`, которая используется и в Python 3, и в Python 2. Подобное применяется не только к написанным нами скриптам, но и к импортированному коду, включая сторонние модули. В результате, большую часть времени (если только вы не пишете код, который запускается лишь один раз) Python занимается выполнением готового байт-кода. Если сравнить это с тем, что происходит в Java и в C\#, окажется, что код на Java компилируется в «Intermediate Language», и виртуальная машина Java читает байт-код и выполняет его JIT-компиляцию в машинный код. «Промежуточный язык» .NET CIL (это то же самое, что .NET Common-Language-Runtime, CLR), использует JIT-компиляцию для перехода к машинному коду. В результате, и в Java и в C\# используется некий «промежуточный язык» и присутствуют похожие механизмы. Почему же тогда Python показывает в бенчмарках гораздо худшие результаты, чем Java и C\#, если все эти языки используют виртуальные машины и какие-то разновидности байт-кода? В первую очередь — из-за того, что в .NET и в Java используется JIT-компиляция. JIT-компиляция (Just In Time compilation, компиляция «на лету» или «точно в срок») требует наличия промежуточного языка для того, чтобы позволить осуществлять разбиение кода на фрагменты (кадры). Системы AOT-компиляции (Ahead Of Time compilation, компиляция перед исполнением) спроектированы так, чтобы обеспечить полную работоспособность кода до того, как начнётся взаимодействие этого кода с системой. Само по себе использование JIT не ускоряет выполнение кода, так как на выполнение поступают, как и в Python, некие фрагменты байт-кода. Однако JIT позволяет выполнять оптимизации кода в процессе его выполнения. Хороший JIT-оптимизатор способен выявить наиболее нагруженные части приложения (такую часть приложения называют «hot spot») и оптимизировать соответствующие фрагменты кода, заменив их оптимизированными и более производительными вариантами, чем те, что использовались ранее. Это означает, что когда некое приложение снова и снова выполняет некие действия, подобная оптимизация способна значительно ускорить выполнение таких действий. Кроме того, не забывайте о том, что Java и C\# — это языки со строгой типизацией, поэтому оптимизатор может делать о коде больше предположений, способствующих улучшению производительности программ. JIT-компилятор есть в PyPy, и, как уже было сказано, эта реализация интерпретатора Python гораздо быстрее, чем CPython. Сведения, касающиеся сравнения разных интерпретаторов Python, можно найти в [этом](https://hackernoon.com/which-is-the-fastest-version-of-python-2ae7c61a6b2b) материале. ### ▍Почему в CPython не используется JIT-компилятор? У JIT-компиляторов есть и недостатки. Один из них — время запуска. CPython и так запускается сравнительно медленно, а PyPy в 2-3 раза медленнее, чем CPython. Длительное время запуска JVM — это тоже известный факт. CLR .NET обходит эту проблему, запускаясь в ходе загрузки системы, но тут надо отметить, что и CLR, и та операционная система, в которой запускается CLR, разрабатываются одной и той же компанией. Если у вас имеется один процесс Python, который работает длительное время, при этом в таком процессе имеется код, который может быть оптимизирован, так как он содержит интенсивно используемые участки, тогда вам стоит серьёзно взглянуть на интерпретатор, имеющий JIT-компилятор. Однако, CPython — это реализация интерпретатора Python общего назначения. Поэтому, если вы разрабатываете, с использованием Python, приложения командной строки, то необходимость длительного ожидания запуска JIT-компилятора при каждом запуске этого приложения сильно замедлит работу. CPython пытается обеспечить поддержку как можно большего количества вариантов использования Python. Например, существует возможности подключения JIT-компилятора к Python, правда, [проект](https://www.slideshare.net/AnthonyShaw5/pyjion-a-jit-extension-system-for-cpython), в рамках которого реализуется эта идея, развивается не особенно активно. В результате можно сказать, что если вы, с помощью Python, пишете программу, производительность которой может улучшиться при использовании JIT-компилятора — используйте интерпретатор PyPy. ## Python — динамически типизированный язык В статически типизированных языках, при объявлении переменных, необходимо указывать их типы. Среди таких языков можно отметить C, C++, Java, C\#, Go. В динамически типизированных языках понятие типа данных имеет тот же смысл, но тип переменной является динамическим. ``` a = 1 a = "foo" ``` В этом простейшем примере Python сначала создаёт первую переменную `a`, потом — вторую с тем же именем, имеющую тип `str`, и освобождает память, которая была выделена первой переменной `a`. Может показаться, что писать на языках с динамической типизацией удобнее и проще, чем на языках со статической типизацией, однако, такие языки созданы не по чьей-то прихоти. При их разработке учтены особенности работы компьютерных систем. Всё, что написано в тексте программы, в итоге, сводится к инструкциям процессора. Это означает, что данные, используемые программой, например, в виде объектов или других типов данных, тоже преобразуются к низкоуровневым структурам. Python выполняет подобные преобразования автоматически, программист этих процессов не видит, и заботиться о подобных преобразованиях ему не нужно. Отсутствие необходимости указывать тип переменной при её объявлении — это не та особенность языка, которая делает Python медленным. Архитектура языка позволяет сделать динамическим практически всё, что угодно. Например, во время выполнения программы можно заменять методы объектов. Опять же, во время выполнения программы можно использовать технику «обезьяньих патчей» в применении к низкоуровневым системным вызовам. В Python возможно практически всё. Именно архитектура Python чрезвычайно усложняет оптимизацию. Для того чтобы проиллюстрировать эту идею, я собираюсь воспользоваться инструментом для трассировки системных вызовов в MacOS, который называется DTrace. В готовом дистрибутиве CPython нет механизмов поддержки DTrace, поэтому CPython нужно будет перекомпилировать с соответствующими настройками. Тут используется версия 3.6.6. Итак, воспользуемся следующей последовательностью действий: ``` wget https://github.com/python/cpython/archive/v3.6.6.zip unzip v3.6.6.zip cd v3.6.6 ./configure --with-dtrace make ``` Теперь, пользуясь `python.exe`, можно применять DTRace для трассировки кода. Об использовании DTrace с Python можно почитать [здесь](https://github.com/paulross/dtrace-py#the-lightning-talk). А вот [тут](https://github.com/paulross/dtrace-py/tree/master/toolkit) можно найти скрипты для измерения с помощью DTrace различных показателей работы Python-программ. Среди них — параметры вызова функций, время выполнения программ, время использования процессора, сведения о системных вызовах и так далее. Вот как пользоваться командой `dtrace`: ``` sudo dtrace -s toolkit/<tracer>.d -c ‘../cpython/python.exe script.py’ ``` А вот как средство трассировки `py_callflow` показывает вызовы функций в приложении. ![](https://habrastorage.org/getpro/habr/post_images/13e/bd4/926/13ebd492636a94b23400305293aec346.gif) Трассировка с использованием DTrace Теперь ответим на вопрос о том, влияет ли динамическая типизация на производительность Python. Вот некоторые соображения по этому поводу: - Проверка и конверсия типов — операции тяжёлые. Каждый раз, когда выполняется обращение к переменной, её чтение или запись, производится проверка типа. - Язык, обладающей подобной гибкостью, сложно оптимизировать. Причина, по которой другие языки настолько быстрее Python, заключается в том, что они идут на те или иные компромиссы, выбирая между гибкостью и производительностью. - Проект [Cython](http://cython.org/) объединяет Python и статическую типизацию, что, например, как показано в [этом материале](http://notes-on-cython.readthedocs.io/en/latest/std_dev.html), приводит к 84-кратному росту производительности в сравнении с применением обычного Python. Обратите внимание на этот проект, если вам нужна скорость. ## Итоги Причиной невысокой производительности Python является его динамическая природа и универсальность. Его можно использовать как инструмент для решения разнообразнейших задач. Для достижения тех же целей можно попытаться поискать более производительные, лучше оптимизированные инструменты. Возможно, найти их удастся, возможно — нет. Приложения, написанные на Python, можно оптимизировать, используя возможности по асинхронному выполнению кода, инструменты профилирования, и — правильно подбирая интерпретатор. Так, для оптимизации скорости работы приложений, время запуска которых неважно, а производительность которых может выиграть от использования JIT-компилятора, рассмотрите возможность использования PyPy. Если вам нужна максимальная производительность и вы готовы к ограничениям статической типизации — взгляните на Cython. Уважаемые читатели\! Как вы решаете проблемы невысокой производительности Python? [![](https://habrastorage.org/r/w1560/files/1ba/550/d25/1ba550d25e8846ce8805de564da6aa63.png)](https://ruvds.com/ru-rub/#order)
Shard	134 (laksa)
Root Hash	14843476518697139734
Unparsed URL	com,habr!/ru/companies/ruvds/articles/418823/ s443