Python проти Bash - в яких видах завдань кожен випереджає інші за рівнем продуктивності?


97

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

Який ваш досвід у цій справі? У якому завданні кожен із них є явним переможцем?


6
Це насправді не опитування, немає жодних попередньо визначених варіантів, мені потрібно трохи зрозуміти, який інструмент найкраще працює, який вид роботи.
Doppelganger

Відповіді:


94

Типовий мейнфрейм ...

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 .

Продуктивність

Це залежить від того, які програми викликає сценарій оболонки Bash та їх придатність для підзадачі, чи буде загальна пропускна здатність та / або швидкість реагування кращою чи гіршою, ніж еквівалентний Python . Щоб ускладнити справи, Python , як і більшість мов, може також викликати інші виконувані файли, хоча він більш громіздкий і, отже, не так часто використовується.

Інтерфейс користувача

Однією з областей, де Python є явним переможцем, є користувальницький інтерфейс. Це робить його чудовою мовою для створення локальних додатків або програм клієнт-сервер, оскільки він спочатку підтримує графіку GTK і є набагато інтуїтивнішим, ніж Bash .

Баш розуміє лише текст. Інші інструменти повинні бути викликані для графічного інтерфейсу та дані, передані з них назад. Python скрипт є одним з варіантів. Швидші, але менш гнучкі варіанти - це бінарні файли, такі як YAD, Zenity та GTKDialog .

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

Підсумок

Побудова сценаріїв оболонки - це все одно, що збирати комп’ютер із готовими компонентами, як це настільні ПК.

Будівництво за допомогою Python , C ++ або більшості інших мов більше нагадує побудову комп’ютера шляхом пайки мікросхем (бібліотек) та інших електронних деталей, як це робить смартфон.

Найкращі результати зазвичай отримуються за допомогою комбінації мов, де кожна з них може робити те, що найкраще робить. Один розробник називає це « програмуванням поліглотів ».


16
Я не розумію, як можна прийняти відповідь. Він не дає жодного уявлення про те, для яких завдань ці два більше підходять.
бдитель

2
@vigilancer Я сподіваюся, що щойно опубліковані зміни та доповнення є корисними.
DocSalvager

1
Хоча я погоджуюсь з іншими коментарями, це точно не відповідає на питання. Це одна з найкращих відповідей, яку я коли-небудь читав!
Джим Мітченер

72

Як правило, bash працює краще, ніж python лише в тих середовищах, де python недоступний. :)

Серйозно кажучи, мені доводиться мати справу з обома мовами щодня, і миттєво перейду на python через bash, якщо йому нададуть вибір. На жаль, я змушений використовувати bash на певних "маленьких" платформах, тому що хтось (помилково, IMHO) вирішив, що python "занадто великий", щоб вмістити його.

Хоча це правда, що bash може бути швидшим, ніж python, для деяких вибраних завдань, він ніколи не може бути настільки швидким для розробки або таким простим в обслуговуванні (принаймні після того, як ви пройдете 10 рядків коду або близько того). Єдиною сильною стороною Баша проти пітона, рубіну чи луа тощо є його повсюдність.


4
Хіба Python вже не на кожному Linux / Unix, навіть MacOS? Мені цікаво, які операції в bash швидші - з того, що я зрозумів, його виклик різних окремих команд робить його набагато повільнішим, ніж команди Python osабо shutilмодулі.
NoBugs

1
@NoBugs Це точно не було б на кожному окремому дистрибутиві Linux / Unix. Він майже напевно поставляється на кожному великому дистрибутиві Linux (наприклад, дистрибутиви на базі debian, слак-програми тощо) та Mac OS X, однак, якщо ви створюєте власний iso за допомогою yocto ( yoctoproject.org ), тоді у вас його не може бути, оскільки Ви самі налаштовуєте кожен пакет. Але, напевно, можна з упевненістю сказати, що для будь-якої великої ОС Unix сьогодні вона буде встановлена ​​з python2 (принаймні) і, можливо, python3 також.
dylnmc

Python - відмінна мова сценаріїв для складних завдань, таких як повнофункціональний графічний інтерфейс. Не менш важливим є те, що він застосовує належні практики програмування, завдяки чому програми легше підтримувати. Баш вимагає впровадження хороших практик, засвоєних в інших місцях, щоб бути ремонтопридатним. Роблячи це, і використовуючи діалогову утиліту графічного інтерфейсу або Python для інтерфейсу, ви отримуєте чудову продуктивність (завдяки надзвичайно швидким програмам, що викликаються з Bash), а також хороший інтерфейс.
DocSalvager

34

Ефективність розробника для мене набагато важливіша у сценаріях, коли і bash, і Python є розумним вибором.

Деякі завдання добре піддаються bash, а інші - Python. Також для мене незвично починати щось як скрипт bash і змінювати його на Python, оскільки воно розвивається протягом декількох тижнів.

Великою перевагою Python є в кутових випадках щодо обробки імен файлів, тоді як він має glob , shutil , підпроцес та інші для загальних потреб сценаріїв.


5
Питання спрямоване на "порівняння продуктивності", яке передбачає продуктивність машини, а не продуктивність розробника. Дивіться мої тести продуктивності в іншій відповіді.
Grzegorz Luczywo

25

Під час написання сценаріїв продуктивність не має значення (у більшості випадків).
Якщо ви піклуєтесь про продуктивність "Python vs Bash" - це помилкове запитання.

Python :
+ простіше писати
+ простіше в обслуговуванні
+ простіше повторне використання коду (спробуйте знайти універсальний спосіб захисту від помилок, щоб включити файли із загальним кодом у sh, я зважусь на вас)
+ ви також можете зробити OOP і з ним!
+ простіший розбір аргументів ну не простіше точно. це все одно буде занадто багатослівним на мій смак, але у python є argparseвбудований об'єкт.
- негарний потворний "підпроцес". спробуйте зв’язати команди і не плакати річкою, якою негарною стане ваш код. особливо якщо ви дбаєте про коди виходу.

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

Якщо один пише сценарій більше ніж 100 LOC: вибрати Python
Якщо одна потреба маніпуляція шлях в скрипті: вибрати Python (3)
Якщо одна потреба кілька як , aliasале трохи складно: вибрати Баш / ш

У будь-якому випадку, слід спробувати обом сторонам зрозуміти, на що вони здатні.

Можливо, відповідь можна розширити за допомогою пунктів упаковки та підтримки IDE, але я не знайомий з цими сторонами.

Як завжди, вам доводиться вибирати з бутерброду з какасом і гігантського спринцювання. І пам’ятайте, що кілька років тому Perl був новою надією. Де воно зараз.


4
Так, код з bash живе вічно. Я закодував багато Perl, вони зараз марні.
Raymond gsh

Тільки для перспективи ... Поточний найбільший сценарій, який я писав, і я використовую його щодня цілий день, важить 4121 рядків фактичного коду bash без коментарів або порожнього рядка. Завдяки великим коментарям та ін., Це складає 7261 рядок. До нього додається файл довідки, схожий на manpage, документи для кожної функції, що становить ще 6650 рядків. Кожна функція має опцію, яка може миттєво отримати та відобразити текст довідки в найкращій доступній формі виводу, яка наразі включає 3 версії YAD, Zenity, діалогового вікна або просто текст CLI. Я називаю це "комплект". це у версії 44 на момент написання статті.
DocSalvager

Це важко! (c)
пильність

1
Я не думаю, що LoC насправді є вирішальним фактором вибору Python. Більше того, наскільки складним є завдання, яке ви виконуєте? Якщо ви просто поєднуєте 100 команд, це, мабуть, добре, якщо це лише 30 LoC в bash, але це може бути простіше зрозуміти в Python - використовуйте python.
JFord

@Akito це нормально, коли це нічого не стосується. але є кілька ситуацій, коли щось може піти не так. ви встановили для нього значення за замовчуванням і забули очистити. щось зовні змінило це, але ваш сценарій покладається на за замовчуванням тощо. завжди потрібно пам’ятати про IFS, оскільки деякі інструменти неявно використовують його.
пильник

22

Баш з точки зору продуктивності перевершує 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

... і /bin/echoперевершує баш на таку величину, важко виміряти. Отже, замість запуску bash, ви можете використовувати /bin/echo mycommand > named_pipe(виводити команди / повідомлення до іменованої труби або сокета) ... і мати фоновий процес Python, який читає команди / інструкції з цієї труби та запускає їх. Таким чином, bash насправді не є хорошою "оптимізацією витрат при запуску".
Чезарій Багінський

Зазвичай вам слід використовувати потоки замість процесів, коли завдання дійсно коротке і швидке. Кілька процесів - це справа високого рівня, і якщо ви запускаєте один півтори секунди, це здебільшого здається досить розумним, чи не скажете ви?
Тимофій Лебедь

16

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

Що швидше? Ні, тому що ви тут не порівнюєте яблука з яблуками. Якщо вам довелося сортувати текстовий файл ascii, і ви використовували такі інструменти, як zcat, sort, uniq та sed, тоді ви будете мудро палити продуктивність Python.

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


13
Тож вся мораль мого висловлювання полягає в тому: використовувати правильний інструмент для правильної роботи.
Джастін,

2
плаваюча точка підтримується такими інструментами, як awk, bc та оболонками типу zsh / ksh, так чому ви кажете, що Python виграє руки?
ghostdog74,

4
Тому що ці інструменти не є Bash. Я вказував на різну різницю. Ці інструменти використовуються в сценарії оболонки, але власний Bash сам не підтримує плаваючу крапку.
Джастін,

2
Ні. Спробуйте самі. gzip великий файл журналу та використовуйте zcat, сортування тощо для фільтрації, а потім використовуйте власні бібліотеки Python. Це значно швидше за допомогою власних інструментів.
Джастін

6
@justin, так, ці інструменти не є Bash, але вони існують з давніх часів і часто використовуються в сценаріях оболонки. якщо ви хочете з плаваючою комою, використовуйте awk / bc. Це поєднання цих інструментів, які роблять сценарії оболонки такими ж потужними, як Python.
ghostdog74,

12

Якщо ви хочете зібрати швидку утиліту з мінімальними зусиллями, це добре. Для обгортки навколо програми bash є безцінним.

Все, що може змусити вас повертатися знову і знову, щоб додати вдосконалення, напевно (хоча і не завжди) більше підходить для такої мови, як Python, оскільки Bash-код, що містить понад 1000 рядків, стає дуже болючим у підтримці. Баш-код також дратує для налагодження, коли він затягується .......

З мого досвіду, частиною проблеми з подібними запитаннями є те, що сценарії оболонки - це, як правило, усі спеціальні завдання. Було дуже мало завдань сценарію оболонки, з якими я стикався там, де вже є вільно доступне рішення.


8

Є два сценарії, коли ефективність Bash принаймні однакова, я вважаю:

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

Тим не менше, я, як правило, не турбуюся про роботу самої мови сценаріїв. Якщо продуктивність справжня проблема, ви не пишете сценарій, а програмуєте (можливо, на Python).


4

Я публікую цю пізню відповідь насамперед тому, що це питання подобається Google.

Я вважаю, що проблема та контекст дійсно повинні стосуватися робочого процесу, а не інструментів. Загальна філософія завжди полягає у тому, щоб "використовувати відповідний інструмент для роботи". Але перед цим виникає той, про який багато хто часто забуває, коли заблукає в інструментах: "Зроби роботу".

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

Але коли проблема починає перевищувати те, що слід попросити зробити Баша? У мене є кілька чеків, які я використовую для попередження:

  1. Чи бажаю я, щоб Баш мав 2D (або вище) масиви? Якщо так, пора зрозуміти, що Bash - це не чудова мова для обробки даних.
  2. Чи роблю я більше роботи з підготовки даних для інших утиліт, ніж я насправді використовую ці утиліти? Якщо так, ще раз зрозуміти Bash - це не чудова мова для обробки даних.
  3. Чи мій сценарій просто стає занадто великим для управління? Якщо так, важливо усвідомити, що хоча Bash може імпортувати бібліотеки сценаріїв, йому не вистачає системи пакетів, як інші мови. Це насправді мова "прокручуй свою" порівняно з більшістю інших. Знову ж таки, він має величезну кількість вбудованих функціональних можливостей (деякі кажуть занадто багато ...)

Список продовжується. Підсумок: коли ви більше працюєте, щоб ваші сценарії працювали, а ви додаєте функції, прийшов час залишити Bash.

Припустимо, ви вирішили перенести свою роботу на Python. Якщо ваші сценарії Bash чисті, первинне перетворення є досить простим. Навіть є кілька перетворювачів / перекладачів, які зроблять перший пропуск за вас.

Наступне питання: Що ви відмовляєтесь від переходу на Python?

  1. Усі дзвінки до зовнішніх утиліт повинні бути загорнуті в щось із subprocessмодуля (або його еквівалента). Для цього існує декілька способів, і до 3.7 потрібно було докласти певних зусиль, щоб це виправити (3.7 вдосконалено subprocess.run()для самостійного вирішення всіх поширених справ).

  2. Дивно, але Python не має стандартної незалежної від платформи утиліти для блокування (з таймаутом) для опитування клавіатури (stdin). Команда Bash read- це чудовий інструмент для простої взаємодії з користувачем. Моє найпоширеніше використання - показувати блешню, доки користувач не натискає клавішу, а також запускати функцію опитування (з кожним кроком спінера), щоб переконатися, що все ще працює добре. Це складніша проблема, ніж це могло б з’явитися спочатку, тому я часто просто телефоную до Bash: Дорого, але вона робить саме те, що мені потрібно.

  3. Якщо ви розробляєте на вбудованій системі або системі, обмеженій пам'яттю, розмір пам'яті Python може бути в рази більшим, ніж розмір Баша (залежно від конкретного завдання). Плюс, майже завжди в пам'яті є екземпляр Bash, що може не стосуватися Python.

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

  5. Python має найповнішу систему пакетів на планеті. Коли Bash стає навіть дещо складним, Python, ймовірно, має пакет, завдяки якому цілі фрагменти Bash стають одним дзвінком. Однак пошук відповідного пакету (пакетів) для використання є найбільшою та найстрашнішою частиною того, як стати Pythonista. На щастя, Google і StackExchange - ваші друзі.


2

Я не знаю, чи це точно, але я виявив, що python / ruby ​​працює набагато краще для сценаріїв, які мають багато математичних обчислень. В іншому випадку вам доведеться використовувати dcабо інший "калькулятор довільної точності". Це просто стає дуже великим болем. За допомогою python ви набагато більше контролюєте floats проти ints, і набагато простіше виконувати багато обчислень, а іноді.

Зокрема, я ніколи не працював би зі сценарієм bash для обробки двійкової інформації або байтів. Натомість я використав би щось на зразок python (можливо) або C ++ або навіть Node.JS.


Арифметика Bash є строго цілим числом, тому вам доведеться виконувати операції з плаваючою комою, викликаючи щось інше (наприклад, awk або dc) і фіксуючи вихідні дані з них. Прості грошові речі часто можна робити внутрішньо, просто помноживши на 100 і відрегулювавши десяткову крапку на виході.
DocSalvager

0

З точки зору продуктивності обидва можуть робити однаково те саме, тому виникає питання, що економить більше часу на розробку?

Bash покладається на виклик інших команд та передачу їх для створення нових. Це має ту перевагу, що ви можете швидко створювати нові програми за допомогою коду, запозиченого у інших людей, незалежно від того, якою мовою програмування вони користувались.

Це також має побічний ефект протистояти змінам підкоманд досить добре, оскільки інтерфейс між ними - це просто текст.

Крім того, Bash дуже дозвільно ставиться до того, як ви можете писати на ньому. Це означає, що він буде добре працювати для широкого кола контекстів, але він також покладається на те, що програміст має намір кодувати чисто і безпечно. Інакше Баш не завадить вам будувати безлад.

Python більш структурований за стилем, тому безладний програміст не буде таким безладним. Він також буде працювати на операційних системах за межами Linux, що робить його миттєво більш доречним, якщо вам потрібна така портативність.

Але це не так просто для виклику інших команд. Тож якщо ваша операційна система Unix, швидше за все, ви виявите, що розробка на Bash - це найшвидший спосіб розвитку.

Коли використовувати Bash:

  • Це не графічна програма, або движок графічної програми.
  • Це лише для Unix.

Коли використовувати Python:

  • Це графічна програма.
  • Він повинен працювати в Windows.
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.