Python vs Bash - Dans quel type de tâches chacun surpasse l'autre en termes de performances?

97

De toute évidence, Python est plus convivial, une recherche rapide sur Google montre de nombreux résultats qui indiquent que, comme Python est compilé par octets, il est généralement plus rapide. J'ai même trouvé cela qui prétend que vous pouvez voir une amélioration de plus de 2000% sur les opérations basées sur le dictionnaire.

Quelle est votre expérience à ce sujet? Dans quel type de tâche chacun est clairement gagnant?

Doppelganger
la source
6
Ce n'est pas en fait un sondage, il n'y a pas d'options prédéfinies, j'ai besoin d'un aperçu de quel outil fonctionne le mieux.
Doppelganger

Réponses:

94

Flux mainframe typique ...

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

Flux Linux typique ...

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                          |
                                   :                          :

Les shells sont la colle de Linux

Les shells Linux comme sh / ksh / bash / ... fournissent des fonctions de désignation d'entrée / sortie / de contrôle de flux un peu comme l'ancien langage de contrôle des travaux mainframe ... mais sous stéroïdes! Ce sont des langages complets de Turing à part entière tout en étant optimisés pour transmettre efficacement les données et le contrôle vers et depuis d'autres processus d'exécution écrits dans n'importe quel langage pris en charge par l'O / S.

La plupart des applications Linux, quelle que soit la langue dans laquelle la majeure partie du programme est écrite, dépendent des scripts shell et Bash est devenu le plus courant. Cliquer sur une icône sur le bureau exécute généralement un court script Bash . Ce script, directement ou indirectement, sait où se trouvent tous les fichiers nécessaires et définit les variables et les paramètres de ligne de commande, appelant finalement le programme. C'est l'utilisation la plus simple d'un shell.

Linux tel que nous le connaissons cependant ne serait guère Linux sans les milliers de scripts shell qui démarrent le système, répondent aux événements, contrôlent les priorités d'exécution et compilent, configurent et exécutent des programmes. Beaucoup d'entre eux sont assez vastes et complexes.

Les shells fournissent une infrastructure qui nous permet d'utiliser des composants pré-construits qui sont liés entre eux au moment de l'exécution plutôt qu'au moment de la compilation. Ces composants sont des programmes autonomes à part entière qui peuvent être utilisés seuls ou dans d'autres combinaisons sans recompilation. La syntaxe pour les appeler est indiscernable de celle d'une commande intégrée Bash , et il existe en fait de nombreuses commandes intégrées pour lesquelles il existe également un exécutable autonome sur le système, ayant souvent des options supplémentaires.

Il n'y a pas de différence de performances entre Python et Bash à l' échelle du langage . Cela dépend entièrement de la manière dont chacun est codé et des outils externes appelés.

N'importe lequel des outils bien connus comme awk, sed, grep, bc, dc, tr, etc. laissera faire ces opérations dans l'une ou l'autre langue dans la poussière. Bash est alors préféré pour tout ce qui n'a pas d'interface utilisateur graphique car il est plus facile et plus efficace d'appeler et de renvoyer des données à partir d'un outil comme ceux avec Bash que Python .

Performance

Cela dépend des programmes appelés par le script shell Bash et de leur adéquation à la sous-tâche qui leur est donnée, que le débit global et / ou la réactivité soient meilleurs ou pires que l'équivalent Python . Pour compliquer les choses, Python , comme la plupart des langages, peut également appeler d'autres exécutables, bien qu'il soit plus lourd et donc moins utilisé.

Interface utilisateur

L' interface utilisateur est un domaine dans lequel Python est clairement le gagnant. Cela en fait un excellent langage pour créer des applications locales ou client-serveur car il prend en charge nativement les graphiques GTK et est beaucoup plus intuitif que Bash .

Bash ne comprend que le texte. D'autres outils doivent être appelés pour une interface graphique et les données renvoyées par eux. Un script Python est une option. Les options plus rapides mais moins flexibles sont les binaires comme YAD, Zenity et GTKDialog .

Alors que les shells comme Bash fonctionnent bien avec les interfaces graphiques telles que Yad , GtkDialog (interface de type XML intégrée aux fonctions GTK +) , dialog et xmessage , Python est beaucoup plus performant et donc meilleur pour les fenêtres graphiques complexes.

Résumé

Construire avec des scripts shell, c'est comme assembler un ordinateur avec des composants prêts à l'emploi comme le sont les ordinateurs de bureau.

Construire avec Python , C ++ ou la plupart des autres langages, c'est plus comme construire un ordinateur en soudant les puces (bibliothèques) et autres composants électroniques ensemble comme le sont les smartphones.

Les meilleurs résultats sont généralement obtenus en utilisant une combinaison de langues où chacun peut faire ce qu'il fait le mieux. Un développeur appelle cela « programmation polyglotte ».

DocSalvager
la source
16
Je ne parviens pas à reconnaître comment cela peut être une réponse acceptée. Il ne fournit aucune indication sur les tâches pour lesquelles ces deux sont les plus adaptés.
vigilancer
2
@vigilancer J'espère que les modifications et ajouts qui viennent d'être publiés sont utiles.
DocSalvager
1
Bien que je sois d'accord avec d'autres commentaires, cela ne répond pas exactement à la question. C'est l'une des meilleures réponses que j'aie jamais lues!
Jim Mitchener
72

En général, bash fonctionne mieux que python uniquement dans les environnements où python n'est pas disponible. :)

Sérieusement, je dois m'occuper des deux langues quotidiennement, et je prendrai python instantanément sur bash si on me donne le choix. Hélas, je suis obligé d'utiliser bash sur certaines "petites" plates-formes parce que quelqu'un a (à tort, à mon humble avis) décidé que python est "trop ​​grand" pour s'adapter.

S'il est vrai que bash peut être plus rapide que python pour certaines tâches sélectionnées, il ne peut jamais être aussi rapide à développer avec, ni aussi facile à maintenir (du moins après avoir dépassé 10 lignes de code environ). Le seul point fort de Bash par rapport au python, au rubis ou au lua, etc., est son ubiquité.

Kevin Little
la source
4
Python n'est-il pas déjà sur tous les Linux / Unix, même MacOS? Je suis curieux de savoir quelles opérations sont plus rapides dans bash - d'après ce que j'ai compris, l'appel de différentes commandes séparées le rend beaucoup plus lent que les commandes de Python osou de shutilmodule.
NoBugs
1
@NoBugs Ce ne serait certainement pas sur toutes les distributions Linux / Unix. Il vient presque certainement sur toutes les distributions Linux majeures (par exemple les distributions basées sur Debian, slackware, etc.) et Mac OS X, cependant, si vous construisez votre propre iso avec yocto ( yoctoproject.org ), alors vous ne pourriez pas l'avoir, car vous personnalisez vous-même chaque package. Mais il est probablement prudent de dire que pour n'importe quel système d'exploitation Unix majeur de nos jours, il sera installé avec python2 (au moins) et peut-être aussi python3.
dylnmc
Python est un excellent langage de script pour les tâches complexes telles qu'une interface graphique complète. Tout aussi important, il applique de bonnes pratiques de programmation afin que les programmes soient plus faciles à maintenir. Bash nécessite l'imposition de bonnes pratiques apprises ailleurs pour être maintenable. Ce faisant, et en utilisant un utilitaire de dialogue GUI ou Python pour UI, donne des performances supérieures (via des programmes utilitaires extrêmement rapides appelés depuis Bash) ainsi qu'une bonne UX.
DocSalvager
34

L'efficacité des développeurs compte beaucoup plus pour moi dans les scénarios où bash et Python sont des choix judicieux.

Certaines tâches se prêtent bien à bash, et d'autres à Python. Il n'est pas non plus inhabituel pour moi de commencer quelque chose en tant que script bash et de le changer en Python à mesure qu'il évolue sur plusieurs semaines.

Un gros avantage de Python est dans les cas secondaires autour de la gestion des noms de fichiers, alors qu'il a glob , shutil , sous - processus et autres pour les besoins de script courants.

Roger Pate
la source
5
La question visait une comparaison «en termes de performances» qui implique les performances de la machine et non les performances du développeur. Voir mes tests de performance dans une autre réponse.
Grzegorz Luczywo
25

Lorsque vous écrivez des scripts, les performances n'ont pas d'importance (dans la plupart des cas).
Si vous vous souciez de la performance 'Python vs Bash' est une fausse question.

Python :
+ plus facile à écrire
+ plus facile à maintenir
+ réutilisation du code plus facile (essayez de trouver un moyen universel et anti-erreur d'inclure des fichiers avec du code commun sh, je vous défie)
+ vous pouvez aussi faire de la POO avec!
+ analyse des arguments plus facile. enfin, pas plus facile, exactement. il sera toujours trop verbeux à mon goût, mais python a argparseune fonction intégrée.
- vilain «sous-processus». essayez d'enchaîner les commandes et de ne pas pleurer à quel point votre code deviendra laid. surtout si vous vous souciez des codes de sortie.

Bash :
+ ubiquité, comme on l'a dit plus tôt, en effet.
+ chaînage de commandes simples. c'est ainsi que vous collez différentes commandes de manière simple. Aussi Bash(pas sh) quelques améliorations, comme pipefail, le chaînage est donc vraiment court et expressif.
+ ne nécessitent pas l'installation de programmes tiers. peut être exécuté immédiatement.
- mon dieu, c'est plein de pièges. IFS, CDPATH .. des milliers d'entre eux.

Si l'on écrit un script plus grand que 100 LOC: choisissez Python
Si l'on a besoin d'une manipulation de chemin dans le script: choisissez Python (3)
Si l'on a besoin d'un peu comme aliasmais légèrement compliqué: choisissez Bash / sh

Quoi qu'il en soit, il faut essayer les deux côtés pour avoir une idée de ce dont ils sont capables.

Peut-être que la réponse peut être étendue avec l'emballage et les points de support IDE, mais je ne suis pas familier avec ces côtés.

Comme toujours, vous devez choisir entre un sandwich à l'étron et une douche géante. Et rappelez-vous, il y a quelques années à peine, Perl était un nouvel espoir. Où il est maintenant.

vigilancer
la source
4
Oui, un code avec bash vit pour toujours. J'ai codé beaucoup de Perl, ils sont désormais inutiles.
Raymond gsh
Juste pour la perspective ... Le plus grand script actuel que j'ai écrit, que j'utilise toute la journée chaque jour, pèse 4121 lignes de code bash réel, sans commentaire ou en ligne vide. Avec les nombreux commentaires et autres, cela fait 7261 lignes. Il est accompagné d'un fichier d'aide contenant des documents de type page de manuel pour chaque fonction, soit 6650 lignes supplémentaires. Chaque fonction a une option qui peut instantanément récupérer et afficher son texte d'aide dans la meilleure forme de sortie disponible qui comprend actuellement 3 versions de YAD, Zenity, dialog ou simplement du texte CLI. Je l'appelle «kit». c'est sur la version 44 au moment d'écrire ces lignes.
DocSalvager
C'est lourd! (c)
vigilancer
1
Je ne pense pas que LoC soit vraiment le facteur décisionnel pour choisir Python. De plus, quelle est la complexité de la tâche que vous effectuez? Si vous ne faites que chaîner 100 commandes, c'est probablement bien, si ce n'est que 30 LoC dans bash mais que cela pourrait être plus facile à comprendre en Python - utilisez python.
JFord
@Akito ça va, quand rien n'y touche. mais il existe quelques situations où les choses pourraient mal tourner. vous l'avez défini sur une valeur par défaut et avez oublié de l'effacer. quelque chose de l'extérieur l'a changé mais votre script repose sur la valeur par défaut, et ainsi de suite. il faut toujours garder IFS à l'esprit, car certains outils l'utilisent implicitement.
vigilancer
22

Bash en termes de performances surpasse Python dans le temps de démarrage du processus.

Voici quelques mesures de mon ordinateur portable Core i7 exécutant 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

* Les bibliothèques chargées en Python sont: os, os.path, json, time, requests, threading, subprocess

Cela montre une énorme différence, mais le temps d'exécution de bash se dégrade rapidement s'il doit faire quelque chose de sensé car il doit généralement appeler des processus externes.

Si vous vous souciez des performances, utilisez bash uniquement pour:

  • scripts vraiment simples et fréquemment appelés
  • scripts qui appellent principalement d'autres processus
  • lorsque vous avez besoin d'un minimum de friction entre les actions administratives manuelles et les scripts - vérifiez rapidement quelques commandes et placez-les dans le fichier .sh
Grzegorz Luczywo
la source
... et /bin/echosurclasse bash d'une telle ampleur, c'est difficile à mesurer. Ainsi, au lieu d'exécuter bash, vous pouvez utiliser /bin/echo mycommand > named_pipe(envoyer des commandes / messages vers un tube ou un socket nommé) ... et avoir un processus Python en arrière-plan lisant les commandes / instructions de ce tube et les exécutant. Donc bash n'est pas vraiment une bonne "optimisation des coûts de démarrage".
Cezary Baginski
Habituellement, vous êtes censé utiliser des threads au lieu de processus lorsque la tâche est vraiment courte et rapide. Les processus multiples sont une chose de haut niveau et tant que le démarrage d'un processus est dans une demi-seconde, cela semble assez raisonnable pour la plupart, n'est-ce pas?
Timothy Swan
16

Bash est principalement un langage de script batch / shell avec beaucoup moins de support pour divers types de données et toutes sortes de bizarreries autour des structures de contrôle - sans parler des problèmes de compatibilité.

Lequel est plus vite? Ni l'un ni l'autre, car vous ne comparez pas ici des pommes à des pommes. Si vous deviez trier un fichier texte ascii et que vous utilisiez des outils tels que zcat, sort, uniq et sed, vous fumerez Python en termes de performances.

Cependant, si vous avez besoin d'un environnement de programmation approprié prenant en charge la virgule flottante et divers flux de contrôle, Python l'emporte haut la main. Si vous avez écrit un algorithme récursif en Bash et Python, la version Python gagnera dans un ordre de grandeur ou plus.

Justin
la source
13
Donc, toute la morale de ma diatribe est la suivante: utiliser le bon outil pour le bon travail.
Justin
2
la virgule flottante est prise en charge avec des outils comme awk, bc et avec des shells comme zsh / ksh, alors pourquoi dites-vous que Python gagne haut la main?
ghostdog74
4
Parce que ces outils ne sont pas Bash. Je signalais une différence distincte. Ces outils sont utilisés dans un script shell, mais natif Bash lui-même ne prend pas en charge la virgule flottante.
Justin
2
Essayez-le vous-même. gzip un fichier journal volumineux et utilisez zcat, sort, etc. pour effectuer un filtrage, puis utilisez les bibliothèques Python natives. C'est beaucoup plus rapide en utilisant les outils natifs.
Justin
6
@justin, oui, ces outils ne sont pas Bash mais ils existent depuis l'Antiquité et sont souvent utilisés dans les scripts shell. si vous voulez une virgule flottante, utilisez awk / bc. C'est une combinaison de ces outils qui rendent le script shell aussi puissant que Python.
ghostdog74
12

Si vous cherchez à concocter un utilitaire rapide avec un minimum d'effort, bash est bien. Pour un wrapper autour d'une application, bash est inestimable.

Tout ce qui peut vous faire revenir encore et encore pour ajouter des améliorations est probablement (mais pas toujours) mieux adapté à un langage comme Python car le code Bash comprenant plus de 1000 lignes devient très pénible à maintenir. Le code Bash est également irritant à déboguer quand il devient long .......

Une partie du problème avec ce genre de questions est, d'après mon expérience, que les scripts shell sont généralement toutes des tâches personnalisées. Il y a eu très peu de tâches de script shell que j'ai rencontrées là où il existe déjà une solution disponible gratuitement.

zamhassam
la source
8

Il y a 2 scénarios où les performances de Bash sont au moins égales je crois:

  • Script des utilitaires de ligne de commande
  • Scripts qui ne prennent que peu de temps à exécuter; où démarrer l'interpréteur Python prend plus de temps que l'opération elle-même

Cela dit, je ne me préoccupe généralement pas vraiment des performances du langage de script lui-même. Si les performances sont un vrai problème, vous ne scriptez pas mais programmez (éventuellement en Python).

extraneon
la source
4

Je poste cette réponse tardive principalement parce que Google aime cette question.

Je pense que le problème et le contexte devraient vraiment concerner le flux de travail, pas les outils. La philosophie générale est toujours «Utiliser le bon outil pour le travail». Mais avant cela, il y en a un que beaucoup oublient souvent lorsqu'ils se perdent dans les outils: «Faites le travail».

Quand j'ai un problème qui n'est pas complètement défini, je commence presque toujours par Bash. J'ai résolu des problèmes épineux dans de gros scripts Bash qui sont à la fois lisibles et maintenables.

Mais quand le problème commence-t-il à dépasser ce que Bash devrait être invité à faire? J'ai quelques contrôles que j'utilise pour me donner des avertissements:

  1. Est-ce que je souhaite que Bash ait des tableaux 2D (ou supérieurs)? Si oui, il est temps de réaliser que Bash n'est pas un excellent langage de traitement de données.
  2. Est-ce que je fais plus de travail pour préparer des données pour d'autres utilitaires que j'exécute réellement ces utilitaires? Si oui, il est temps de réaliser que Bash n'est pas un excellent langage de traitement de données.
  3. Mon script devient-il simplement trop volumineux pour être géré? Si oui, il est important de réaliser que si Bash peut importer des bibliothèques de scripts, il lui manque un système de paquets comme les autres langages. C'est vraiment un langage "roll your own" comparé à la plupart des autres. Là encore, il a une énorme quantité de fonctionnalités intégrées (certains en disent trop ...)

La liste continue. En fin de compte, lorsque vous travaillez plus dur pour maintenir vos scripts en cours d'exécution que vous ajoutez des fonctionnalités, il est temps de quitter Bash.

Supposons que vous ayez décidé de déplacer votre travail vers Python. Si vos scripts Bash sont propres, la conversion initiale est assez simple. Il existe même plusieurs convertisseurs / traducteurs qui feront le premier passage pour vous.

La question suivante est: à quoi renoncez-vous en passant à Python?

  1. Tous les appels à des utilitaires externes doivent être enveloppés dans quelque chose du subprocessmodule (ou équivalent). Il y a plusieurs façons de faire cela, et jusqu'à 3.7, il a fallu quelques efforts pour bien faire les choses (3.7 amélioré subprocess.run()pour gérer tous les cas courants par lui-même).

  2. Étonnamment, Python n'a pas d'utilitaire standard non bloquant indépendant de la plate-forme (avec timeout) pour interroger le clavier (stdin). La readcommande Bash est un outil génial pour une interaction utilisateur simple. Mon utilisation la plus courante est d'afficher un spinner jusqu'à ce que l'utilisateur appuie sur une touche, tout en exécutant également une fonction d'interrogation (à chaque étape de spinner) pour m'assurer que les choses fonctionnent toujours bien. C'est un problème plus difficile qu'il n'y paraît au premier abord, donc je passe souvent simplement un appel à Bash: cher, mais il fait précisément ce dont j'ai besoin.

  3. Si vous développez sur un système embarqué ou à mémoire limitée, l'empreinte mémoire de Python peut être plusieurs fois plus grande que celle de Bash (en fonction de la tâche à accomplir). De plus, il y a presque toujours une instance de Bash déjà en mémoire, ce qui peut ne pas être le cas pour Python.

  4. Pour les scripts qui s'exécutent une fois et se terminent rapidement, le temps de démarrage de Python peut être beaucoup plus long que celui de Bash. Mais si le script contient des calculs importants, Python avance rapidement.

  5. Python possède le système de paquets le plus complet de la planète. Lorsque Bash devient même légèrement complexe, Python a probablement un package qui transforme des morceaux entiers de Bash en un seul appel. Cependant, trouver le (s) bon (s) package (s) à utiliser est la partie la plus importante et la plus intimidante pour devenir un Pythonista. Heureusement, Google et StackExchange sont vos amis.

BobC
la source
2

Je ne sais pas si c'est exact, mais j'ai trouvé que python / ruby ​​fonctionnait beaucoup mieux pour les scripts qui ont beaucoup de calculs mathématiques. Sinon, vous devez utiliser dcou une autre "calculatrice de précision arbitraire". Cela devient juste une très grosse douleur. Avec python, vous avez beaucoup plus de contrôle sur les floats que sur les ints et il est beaucoup plus facile d'effectuer beaucoup de calculs et parfois.

En particulier, je ne travaillerais jamais avec un script bash pour gérer des informations binaires ou des octets. Au lieu de cela, j'utiliserais quelque chose comme python (peut-être) ou C ++ ou même Node.JS.

dylnmc
la source
L'arithmétique bash est strictement entière, vous devez donc effectuer des opérations en virgule flottante en appelant autre chose (comme awk ou dc) et en capturant la sortie. Des opérations monétaires simples peuvent souvent être effectuées en interne en multipliant simplement par 100 et en ajustant le point décimal dans la sortie.
DocSalvager
0

En termes de performances, les deux peuvent faire la même chose, donc la question est de savoir qui économise plus de temps de développement?

Bash s'appuie sur l'appel d'autres commandes et leur acheminement pour en créer de nouvelles. Cela présente l'avantage de pouvoir créer rapidement de nouveaux programmes simplement avec le code emprunté à d'autres personnes, quel que soit le langage de programmation utilisé.

Cela a également pour effet secondaire de résister assez bien au changement des sous-commandes, car l'interface entre elles n'est que du texte brut.

De plus, Bash est très permissif sur la façon dont vous pouvez écrire dessus. Cela signifie qu'il fonctionnera bien pour une plus grande variété de contextes, mais cela dépend également du programmeur ayant l'intention de coder de manière propre et sûre. Sinon, Bash ne vous empêchera pas de créer un désordre.

Python est plus structuré sur le style, donc un programmeur désordonné ne sera pas aussi compliqué. Il fonctionnera également sur les systèmes d'exploitation en dehors de Linux, ce qui le rend instantanément plus approprié si vous avez besoin de ce type de portabilité.

Mais ce n'est pas aussi simple pour appeler d'autres commandes. Donc, si votre système d'exploitation est Unix, vous constaterez probablement que le développement sur Bash est le moyen le plus rapide de développer.

Quand utiliser Bash:

  • C'est un programme non graphique, ou le moteur d'un programme graphique.
  • C'est uniquement pour Unix.

Quand utiliser Python:

  • C'est un programme graphique.
  • Il fonctionnera sous Windows.
Alberto Salvia Novella
la source