Python против Bash - В каких задачах каждая из них превосходит другие по производительности?

Question

Очевидно, что Python более удобен для пользователя, быстрый поиск в Google показывает много результатов, которые говорят, что, поскольку Python компилируется байтами, он обычно быстрее Я даже нашел этот , который утверждает, что вы можете увидеть улучшение более чем на 2000% в словарных операциях.

Каков ваш опыт в этом вопросе? В каком задании каждый из них является явным победителем?

Answer 1

Типичный поток основного блока ...

Input Disk/Tape/User (runtime) --> Job Control Language (JCL) --> Output Disk/Tape/Screen/Printer
                                   |                          ^
                                   v                          |
                                   `--> COBOL Program --------' 

Типичный поток Linux ...

Input Disk/SSD/User (runtime) --> sh/bash/ksh/zsh/... ----------> Output Disk/SSD/Screen/Printer
                                   |                          ^
                                   v                          |
                                   `--> Python script --------'
                                   |                          ^
                                   v                          |
                                   `--> awk script -----------'
                                   |                          ^
                                   v                          |
                                   `--> sed script -----------'
                                   |                          ^
                                   v                          |
                                   `--> C/C++ program --------'
                                   |                          ^
                                   v                          |
                                   `--- Java program ---------'
                                   |                          ^
                                   v                          |
                                   :                          :

Оболочки - это клей Linux

Оболочки Linux, такие как sh / ksh / bash / ..., предоставляют средства обозначения ввода / вывода / управления потоком, очень похожие на старый язык управления заданиями мэйнфрейма ... но на стероидах! Они являются полными языками Тьюринга сами по себе, при этом они оптимизированы для эффективной передачи данных и управления другим выполняющимся процессам, написанным на любом языке, поддерживаемом O / S.

Большинство приложений Linux, независимо от того, на каком языке написана основная часть программы, зависят от сценариев оболочки, и Bash стал наиболее распространенным. При щелчке значка на рабочем столе обычно запускается короткий Bash скрипт. Этот скрипт, прямо или косвенно, знает, где находятся все необходимые файлы, и устанавливает переменные и параметры командной строки, наконец, вызывая программу. Это самое простое использование оболочки.

Linux, каким мы его знаем, вряд ли будет Linux без тысяч сценариев оболочки, которые запускают систему, отвечают на события, контролируют приоритеты выполнения и компилируют, конфигурируют и запускают программы. Многие из них довольно большие и сложные.

Оболочки предоставляют инфраструктуру, которая позволяет нам использовать предварительно созданные компоненты, которые связаны во время выполнения, а не во время компиляции. Эти компоненты являются самостоятельными программами, которые могут использоваться отдельно или в других комбинациях без перекомпиляции. Синтаксис для их вызова неотличим от синтаксиса встроенной команды Bash , и на самом деле существует множество встроенных команд, для которых в системе также есть отдельный исполняемый файл, часто с дополнительными параметрами.

Нет общеязыковой разницы между Python и Bash в производительности. Это полностью зависит от того, как каждый кодируется и какие внешние инструменты называются.

Любые хорошо известных инструментов, таких как awk, sed, grep, bc, dc, tr, и т. Д., Оставят выполнение этих операций на любом языке в пыли. Bash тогда предпочтительнее для всего, что не имеет графического пользовательского интерфейса, поскольку проще и эффективнее вызывать и передавать данные из инструмента, подобного тем, которые имеют Bash , чем Python .

Performance

Это зависит от того, какие программы вызывают скрипты оболочки Bash и их пригодность для заданной подзадачи, будет ли общая пропускная способность и / или скорость отклика лучше или хуже, чем у эквивалентного Python . Чтобы усложнить ситуацию, Python , как и большинство языков, может также вызывать другие исполняемые файлы, хотя это более громоздко и поэтому используется не так часто.

Пользовательский интерфейс

Одна область, где Python - явный победитель, - это пользовательский интерфейс. Это делает его отличным языком для создания локальных или клиент-серверных приложений, поскольку он изначально поддерживает графику GTK и гораздо более интуитивен, чем Bash .

Bash понимает только текст. Другие инструменты должны быть вызваны для графического интерфейса и данных, передаваемых от них. Скрипт Python является одним из вариантов. Более быстрыми, но менее гибкими вариантами являются бинарные файлы, такие как YAD, Zenity и GTKDialog .

Хотя оболочки типа Bash хорошо работают с графическими интерфейсами, такими как Яд , GtkDialog (встроенный XML-подобный интерфейс для функций GTK +) , диалоговое окно и xmessage , Python обычно проще и более способны.

Резюме

Сборка с использованием сценариев оболочки похожа на сборку компьютера с готовыми компонентами, как настольные ПК.

Сборка с Python , C ++ или почти любым другим языком больше похожа на сборку компьютера путем пайки микросхем (библиотек) и других электронных компонентов вместе, как смартфоны.

Answer 2

Как правило, bash работает лучше, чем python, только в тех средах, где python недоступен. :)

Серьезно, мне приходится иметь дело с обоими языками каждый день, и я приму Python мгновенно через bash, если будет предоставлен выбор. Увы, я вынужден использовать bash на некоторых «маленьких» платформах, потому что кто-то (по ошибке, ИМХО) решил, что python «слишком большой» для размещения.

Несмотря на то, что bash может быть быстрее, чем python, для некоторых избранных задач, он никогда не может быть настолько быстрым для разработки или настолько простым в обслуживании (по крайней мере, после того, как вы получите 10 или более строк кода). Единственная сильная сторона Баша по отношению к питону, рубину или луа и т. Д. - это его повсеместное распространение.

Answer 3

Эффективность разработчика для меня гораздо важнее в сценариях, где разумным выбором являются и bash, и Python.

Некоторые задачи хорошо подходят для bash, а другие - для Python. Для меня также нередко начинать что-то как скрипт bash и менять его на Python, так как он развивается в течение нескольких недель.

Большое преимущество, которое Python имеет в угловых случаях, связанных с обработкой имен файлов, в то время как он имеет glob , shutil , подпроцесс и другие для общих нужд сценариев.

Answer 4

При написании скриптов производительность не имеет значения (в большинстве случаев).
Если вы заботитесь о производительности, «Python vs Bash» - ложный вопрос.

Python
+ проще написать
+ проще в обслуживании
+ более простое повторное использование кода (попробуйте найти универсальный, защищенный от ошибок способ включения файлов с общим кодом в sh, смею вас)
+ с этим тоже можно делать ООП!
+ проще разбор аргументов. ну не проще точно. это все еще будет слишком многословно на мой вкус, но в python встроено argparse средство.
уродливый уродливый подпроцесс. старайтесь объединять команды и не плакать рекой, насколько уродливым станет ваш код. особенно если вы заботитесь о кодах выхода.

Баш
+ повсеместность, как уже было сказано ранее.
+ простая цепочка команд. Вот так просто склеивать разные команды. Также Bash (не sh) имеет некоторые улучшения, такие как pipefail, поэтому цепочка действительно короткая и выразительная.
+ не требуют установки сторонних программ. можно выполнить сразу.
- Боже, он полон ошибок. IFS, CDPATH .. тысячи из них.

Если один пишет скрипт больше 100 LOC: выберите Python
Если в скрипте требуется манипулирование путём: выберите Python (3)
Если нужно что-то вроде alias, но немного сложнее: выберите Bash / sh

В любом случае, нужно попробовать обе стороны, чтобы понять, на что они способны.

Возможно, ответ можно дополнить точками упаковки и поддержки IDE, но я не знаком с этими сторонами.

Как всегда, вам нужно выбрать бутерброд с какашками и гигантский душ. И помните, всего несколько лет назад у Perl появилась новая надежда. Где это сейчас.

Answer 5

По производительности bash превосходит python во время запуска процесса.

Вот некоторые измерения от моего основного ноутбука i7 под управлением Linux Mint:

Starting process                       Startup time

empty /bin/sh script                   1.7 ms
empty /bin/bash script                 2.8 ms
empty python script                    11.1 ms
python script with a few libs*         110 ms

* Загруженные Python библиотеки: os, os.path, json, время, запросы, потоки, подпроцесс

Это показывает огромную разницу, однако время выполнения bash быстро уменьшается, если оно должно делать что-то разумное, поскольку обычно оно должно вызывать внешние процессы.

Если вы заботитесь о производительности, используйте bash только для:

• действительно простые и часто вызываемые скрипты
• скрипты, которые в основном вызывают другие процессы
• если вам нужно минимальное трение между административными действиями и сценариями - быстро проверьте несколько команд и поместите их в файл .sh

Answer 6

Bash - это, прежде всего, язык сценариев пакетной обработки / оболочки, с гораздо меньшей поддержкой различных типов данных и всевозможных причуд в структурах управления - не говоря уже о проблемах совместимости.

Что быстрее? Нет, потому что вы не сравниваете яблоки с яблоками здесь. Если вам нужно было отсортировать текстовый файл ascii и вы использовали такие инструменты, как zcat, sort, uniq и sed, то вы покушаете на производительность Python.

Однако, если вам нужна правильная среда программирования, которая поддерживает плавающую точку и различные потоки управления, Python выигрывает. Если вы написали, скажем, рекурсивный алгоритм в Bash и Python, версия Python выиграет на порядок и более.

Answer 7

Если вы хотите собрать быструю утилиту с минимальными усилиями, bash - это хорошо. Для оболочки вокруг приложения bash бесценен.

Все, что может заставить вас возвращаться снова и снова для добавления улучшений, вероятно (хотя и не всегда) лучше подходит для такого языка, как Python, поскольку Bash-код, содержащий более 1000 строк, становится очень болезненным для поддержки. Код Bash также раздражает отладку, когда он становится длинным .......

Часть проблемы с такими вопросами, по моему опыту, состоит в том, что сценарии оболочки обычно представляют собой пользовательские задачи. Было очень мало задач сценариев оболочки, с которыми я сталкивался, когда уже есть бесплатное решение.

Answer 8

Существует 2 сценария, в которых производительность Bash, по крайней мере, равна:

• Скрипты утилит командной строки
• Сценарии, выполнение которых занимает очень короткое время; где запуск интерпретатора Python занимает больше времени, чем сама операция

Тем не менее, я обычно не особо беспокоюсь о производительности самого языка сценариев. Если производительность является реальной проблемой, вы не пишете сценарий, а программируете (возможно, на Python).

Answer 9

Я не знаю, насколько это точно, но я обнаружил, что python / ruby ​​работает намного лучше для сценариев, которые имеют много математических вычислений. В противном случае вам придется использовать dc или другой «калькулятор произвольной точности». Это просто становится очень большой болью. С python у вас гораздо больше контроля над плавающими по сравнению с целыми числами, и гораздо проще выполнять много вычислений, а иногда.

В частности, я бы никогда не работал со скриптом bash для обработки двоичной информации или байтов. Вместо этого я бы использовал что-то вроде Python (может быть) или C ++ или даже Node.JS.

Answer 10

Я публикую этот поздний ответ главным образом потому, что Google любит этот вопрос.

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

Когда у меня возникает проблема, которая не полностью определена, я почти всегда начинаю с Bash. Я решил несколько грубых проблем в больших скриптах Bash, которые доступны для чтения и сопровождения.

Но когда проблема начинает превышать то, что нужно попросить сделать Bash? У меня есть несколько проверок, которые я использую для предупреждения:

1. Хотел бы я, чтобы у Bash были 2D (или выше) массивы? Если да, пришло время понять, что Bash не является отличным языком обработки данных.
2. Я делаю больше работы по подготовке данных для других утилит, чем на самом деле запускаю эти утилиты? Если да, еще раз, чтобы понять, что Bash не является отличным языком обработки данных.
3. Мой сценарий слишком велик для управления? Если да, важно понимать, что, хотя Bash может импортировать библиотеки скриптов, ему не хватает системы пакетов, как в других языках. Это действительно язык "кати свой" по сравнению с большинством других. Опять же, он имеет огромное количество встроенных функций (некоторые говорят, что слишком много ...)

Список можно продолжить. В итоге, когда вы усердно работаете над тем, чтобы ваши скрипты работали, а вы добавляете функции, пришло время покинуть Bash.

Предположим, вы решили перенести свою работу на Python. Если ваши скрипты Bash чистые, первоначальное преобразование довольно простое. Есть даже несколько конвертеров / переводчиков, которые сделают вам первый проход.

Следующий вопрос: что вы бросаете переходить на Python?

1. Все вызовы внешних утилит должны быть заключены во что-то из модуля subprocess (или эквивалентного). Есть несколько способов сделать это, и до 3.7 потребовалось некоторое усилие, чтобы сделать это правильно (3.7 улучшено subprocess.run() для обработки всех общих случаев самостоятельно).

2. Удивительно, но в Python нет стандартной независимой от платформы неблокирующей утилиты (с тайм-аутом) для опроса клавиатуры (стандартный ввод). Команда Bash read является отличным инструментом для простого взаимодействия с пользователем. Мое наиболее распространенное использование - показывать счетчик, пока пользователь не нажмет клавишу, и одновременно запустить функцию опроса (с каждым шагом счетчика), чтобы убедиться, что все работает хорошо. Это сложнее, чем кажется на первый взгляд, поэтому я часто просто звоню Bash: Дорого, но он делает именно то, что мне нужно.

3. Если вы разрабатываете на встраиваемой или ограниченной по памяти системе, объем памяти Python может быть во много раз больше, чем у Bash (в зависимости от поставленной задачи). Кроме того, в памяти почти всегда есть экземпляр Bash, чего не может быть в Python.

4. Для скриптов, которые запускаются один раз и быстро завершаются, время запуска Python может быть намного больше, чем время запуска Bash. Но если сценарий содержит значительные вычисления, Python быстро продвигается вперед.

5. У Python самая всеобъемлющая система пакетов на планете. Когда Bash становится немного сложнее, у Python, вероятно, есть пакет, который превращает целые куски Bash в один вызов. Тем не менее, найти правильный пакет (ы) для использования является самой большой и самой сложной частью становления Pythonista. К счастью, Google и StackExchange - ваши друзья.