Очевидно, что Python более удобен в использовании, быстрый поиск в google показывает много результатов, которые говорят, что, поскольку Python байт-скомпилирован, как правило, быстрее. Я даже нашел этот, который утверждает, что вы можете увидеть улучшение более чем на 2000% в словарных операциях.
Каков ваш опыт в этом вопросе? В какой задаче каждый из них является явным победителем?
Типичный поток мэйнфреймов...
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, такие как sh/ksh/bash/..., предоставляют средства обозначения ввода/вывода/управления потоком, очень похожие на старый язык управления заданиями мэйнфрейма... но на стероидах! Они сами по себе являются полноценными языками и оптимизированы для эффективной передачи данных и управления другим выполняющимся процессам, написанным на любом языке, поддерживаемом O/S, и от него.
Большинство приложений Linux, независимо от того, на каком языке написана основная часть программы, зависят от сценариев оболочки, и Bash стал наиболее распространенным. При щелчке значка на рабочем столе обычно запускается короткий Bash скрипт. Этот скрипт, прямо или косвенно, знает, где находятся все необходимые файлы, и устанавливает переменные и параметры командной строки, наконец, вызывая программу. Это оболочка простейшего использования.
Linux, как мы его знаем, вряд ли будет Linux без тысяч сценариев оболочки, которые запускают систему, отвечают на события, управляют приоритетами выполнения и компилируют, конфигурируют и запускают программы. Многие из них довольно большие и сложные.
Оболочки обеспечивают инфраструктуру, которая позволяет нам использовать предварительно созданные компоненты, которые связаны во время выполнения, а не во время компиляции. Эти компоненты являются самостоятельными программами, которые могут использоваться отдельно или в других комбинациях без перекомпиляции. Синтаксис их вызова неотличим от синтаксиса встроенной команды Bash, и на самом деле существует множество встроенных команд, для которых в системе также есть отдельный исполняемый файл, часто имеющий дополнительные параметры.
Различия между Python и Bash в производительности между языками отсутствуют. Это полностью зависит от того, как каждый кодируется и какие внешние инструменты называются.
Любой из хорошо известных инструментов, таких как awk, sed, grep, bc, dc, tr, и т.д., Оставит выполнение этих операций на любом языке в мусоре. Bash тогда предпочтительнее для всего, что не имеет графического пользовательского интерфейса, поскольку проще и эффективнее вызывать и передавать данные из инструмента, подобного тем, которые используют Bash, чем Python.
Это зависит от того, какие программы вызывает Bash сценарий оболочки и их пригодность для заданной им подзадачи, будет ли общая пропускная способность и/или скорость отклика лучше или хуже эквивалентного Python. Чтобы усложнить ситуацию, Python, как и большинство языков, может также вызывать другие исполняемые файлы, хотя это более громоздко и поэтому используется не так часто.
Пользовательский интерфейс - это та область, где Python является явным победителем. Это делает его отличным языком для создания локальных или клиент-серверных приложений, поскольку он изначально поддерживает графику GTK и намного более интуитивен, чем Bash.
Bash понимает только текст. Другие инструменты должны быть вызваны для графического интерфейса и данных, передаваемых от них. Сценарий Python является одним из вариантов. Более быстрыми, но менее гибкими параметрами являются такие двоичные файлы, как YAD, Zenity и GTKDialog.
В то время как оболочки типа Bash хорошо работают с графическими интерфейсами, такими как Yad, GtkDialog (встроенный XML-подобный интерфейс для функций GTK+), диалог и xmessage, Python обычно проще и эффективнее.
Сборка с использованием сценариев оболочки похожа на сборку компьютера с готовыми компонентами, как настольные ПК.
Сборка с использованием Python, C++ или большинства других языков больше похожа на сборку компьютера путем пайки микросхем (библиотек) и других электронных компонентов вместе, как смартфоны.
Как правило, bash работает лучше, чем python, только в тех средах, где python недоступен.:)
Серьезно, мне приходится иметь дело с обоими языками ежедневно, и я буду принимать python мгновенно через bash, если вам будет дан выбор. Увы, я вынужден использовать bash на определенных "малых" платформах, потому что кто-то (ошибочно, IMHO) решил, что python "слишком велик", чтобы соответствовать.
Хотя верно, что bash может быть быстрее, чем python для некоторых задач выбора, он никогда не может быть таким быстрым, чтобы развиваться с ним или как легко поддерживать (по крайней мере, после того, как вы получите 10 строк кода или так далее), bash единственная сильная точка для python или ruby или lua и т.д. - это ее вездесущность.
Эффективность разработчика гораздо важнее для меня в сценариях, где оба bash и Python - разумные варианты.
Некоторые задачи хорошо подходят для bash, а другие - для Python. Для меня также не является чем-то начинать что-то как bash script и менять его на Python, поскольку он развивается в течение нескольких недель.
Большое преимущество Python заключается в том, что в обработчике файлов есть угловые случаи, в то время как glob, shutil, subprocess, а другие - для обычных сценариев.
При написании скриптов производительность не имеет значения (в большинстве случаев).
Если вы заботитесь о производительности "Python vs Bash", это ложный вопрос.
Python:
+ проще написать
+ проще в обслуживании
+ более легкое повторное использование кода (попробуйте найти универсальный защищенный от ошибок способ включения файлов с общим кодом в sh, я смею вас)
+ вы тоже можете делать ООП!
+ простой анализ аргументов. ну, не проще, точно. он по-прежнему будет слишком многословным на мой вкус, но у python есть встроенный объект argparse.
- уродливый уродливый "подпроцесс". попытайтесь цеплять команды и не плакать рекой, насколько уродливым станет ваш код. особенно если вы заботитесь о кодах выхода.
Bash:
+ вездесущность, как было сказано ранее.
+ простая цепочка команд. что как вы склеиваете разные команды простым способом. Также Bash (not sh) имеют некоторые улучшения, такие как pipefail, поэтому цепочка действительно короткая и выразительная.
+ не требуют установки сторонних программ. могут быть выполнены сразу.
- Боже, он полон страхов. IFS, CDPATH.. тысячи из них.
Если вы пишете script больше 100 LOC: выберите Python
Если нужна обработка пути в script: выберите Python (3)
Если нужно немного как alias, но немного сложно: выберите Bash/sh
В любом случае, нужно попытаться обеими сторонами понять, на что они способны.
Возможно, ответ может быть расширен с помощью точек поддержки упаковки и IDE, но я не знаком с этими сторонами.
Как всегда вам приходится выбирать из бутерброда и гигантского душа. И помните, что всего несколько лет назад Перл был новой надеждой. Где это сейчас.
Производительность 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 только для:
Bash - это, в первую очередь, язык сценариев пакетной/командной строки с гораздо меньшей поддержкой различных типов данных и всевозможных причуд вокруг структур управления - не говоря уже о проблемах совместимости.
Что быстрее? Ни то, что вы не сравниваете яблоки с яблоками здесь. Если вам пришлось сортировать текстовый файл ascii, и вы использовали такие инструменты, как zcat, sort, uniq и sed, вы будете курить Python.
Однако, если вам нужна правильная среда программирования, которая поддерживает плавающие точки и различные потоки управления, то Python выигрывает руки. Если вы написали рекурсивный алгоритм в Bash и Python, версия Python будет выигрывать по порядку величины или больше.
Если вы ищете возможность быстрой сборки быстрой утилиты с минимальными усилиями, bash это хорошо. Для оболочки вокруг приложения bash неоценим.
Все, что может потребоваться для добавления улучшений, возможно, (хотя и не всегда), лучше подходит для языка, такого как Python, поскольку код bash, содержащий более 1000 строк, очень болезнен для поддержания. bash код также раздражает отладку, когда он становится длинным........
Часть проблемы с такими вопросами, по моему опыту, заключается в том, что сценарии оболочки обычно представляют собой все пользовательские задачи. Там было очень мало задач сценария оболочки, с которыми я столкнулся, где уже доступно свободное решение.
Существует 2 сценария, в которых производительность Bash равна хотя бы равным. Я полагаю:
Тем не менее, я, как правило, не очень забочусь о производительности самого скриптового языка. Если производительность является реальной проблемой, вы не script, а программа (возможно, на Python).
Я не знаю, насколько это точно, но я обнаружил, что python/ruby работает намного лучше для скриптов, которые имеют множество математических вычислений. В противном случае вы должны использовать dc или какой-либо другой "калькулятор произвольной точности". Это просто становится большой болью. С python у вас гораздо больше контроля над float vs ints, и гораздо проще выполнять множество вычислений и иногда.
В частности, я бы никогда не работал с bash script для обработки двоичной информации или байтов. Вместо этого я бы использовал что-то вроде python (возможно) или С++ или даже Node.JS.
Я публикую этот поздний ответ в первую очередь потому, что Google любит этот вопрос.
Я считаю, что проблема и контекст действительно должны касаться рабочего процесса, а не инструментов. Общая философия всегда такова: "Используйте правильный инструмент для работы". Но перед этим стоит тот, о котором многие часто забывают, когда теряются в инструментах: "Выполни работу".
Когда у меня есть проблема, которая не полностью определена, я почти всегда начинаю с Bash. Я решил несколько грубых проблем в больших скриптах Bash, которые читаются и обслуживаются.
Но когда проблема начинает превышать то, что нужно попросить сделать Bash? У меня есть несколько проверок, которые я использую для предупреждения:
Список можно продолжить. В итоге, когда вы усердно работаете над тем, чтобы ваши скрипты работали, а вы добавляете функции, самое время оставить Bash.
Предположим, вы решили перенести свою работу на Python. Если ваши скрипты Bash чистые, первоначальное преобразование довольно простое. есть даже несколько конвертеров/переводчиков, которые сделают вам первый проход.
Следующий вопрос: что вы отказываетесь от перехода на Python?
Все вызовы внешних утилит должны быть заключены во что-то из модуля subprocess (или эквивалентного). Есть несколько способов сделать это, и до 3.7 потребовалось некоторое усилие, чтобы сделать это правильно (3.7 улучшил subprocess.run() для обработки всех общих случаев самостоятельно).
Удивительно, но в Python нет стандартной независимой от платформы неблокирующей утилиты (с таймаутом) для опроса клавиатуры (stdin). Команда Bash read является отличным инструментом для простого взаимодействия с пользователем. Мое наиболее распространенное использование - показывать счетчик, пока пользователь не нажмет клавишу, и одновременно запустить функцию опроса (с каждым шагом счетчика), чтобы убедиться, что все работает хорошо. Это сложнее, чем кажется на первый взгляд, поэтому я часто просто звоню Bash: дорого, но он делает именно то, что мне нужно.
Если вы разрабатываете встраиваемую систему или систему с ограниченным объемом памяти, объем памяти Python может быть во много раз больше, чем у Bash (в зависимости от поставленной задачи). Кроме того, в памяти почти всегда есть экземпляр Bash, чего не может быть в Python.
Для скриптов, которые запускаются один раз и быстро завершаются, время запуска Python может быть намного больше, чем у Bash. Но если сценарий содержит значительные вычисления, Python быстро продвигается вперед.
У Python самая всеобъемлющая система пакетов на планете. Когда Bash становится немного сложнее, у Python, вероятно, есть пакет, который превращает целые куски Bash в один вызов. Тем не менее, найти правильный пакет для использования является самой большой и самой сложной частью становления Pythonista. К счастью, Google и StackExchange - ваши друзья.