116 votes

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

Il est évident que Python est plus facile à utiliser, une recherche rapide sur Google montre de nombreux résultats qui disent que, comme Python est compilé par octet, il est généralement plus rapide. J'ai même trouvé ce qui prétend que vous pouvez constater une amélioration de plus de 2000% sur les opérations basées sur les dictionnaires.

Quelle est votre expérience en la matière ? Dans quel type de tâche chacun d'entre eux est clairement gagnant ?

2 votes

Python est drastiquement plus rapide sur le traitement de texte, qui est une opération courante. Si j'effectue la même recherche 10000 fois sur chaque langue, sur Bash il faut 1m24s, sur Python 636ms. Cela s'explique par le fait que Bash utilise un sous-processus pour chaque opération du traitement de texte, ce qui est lent à créer.

20voto

Justin Points 89

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

Lequel est le plus rapide ? Aucune, car vous ne comparez pas des pommes avec des pommes. Si vous deviez trier un fichier texte ascii et que vous utilisiez des outils tels que zcat, sort, uniq et sed, vous feriez une belle jambe à Python en termes de performances.

Toutefois, si vous avez besoin d'un environnement de programmation adéquat prenant en charge la virgule flottante et divers flux de contrôle, alors Python l'emporte haut la main. Si vous écrivez un algorithme récursif en Bash et en Python, la version Python l'emportera d'un ordre de grandeur ou plus.

15 votes

La morale de ma diatribe est donc la suivante : utilisez le bon outil pour le bon travail.

2 votes

La virgule flottante est prise en charge par des outils comme awk, bc et des shells comme zsh/ksh, alors pourquoi dites-vous que Python l'emporte haut la main ?

5 votes

Parce que ces outils ne sont pas Bash. Je soulignais une différence distincte. Ces outils sont utilisés dans un shell script, mais le Bash natif lui-même ne supporte pas la virgule flottante.

13voto

BobC Points 147

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

Je pense que la question et le contexte devraient vraiment porter sur le flux de travail, et non sur les outils. La philosophie générale est toujours "Utiliser le bon outil pour le travail". Mais avant cela, il y a une chose que beaucoup oublient souvent lorsqu'ils se perdent dans les outils : "Faites le travail."

Lorsque 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 grands scripts Bash qui sont à la fois lisibles et faciles à maintenir.

Mais à partir de quand le problème commence-t-il à dépasser ce qu'il faut demander à Bash ? J'ai quelques contrôles que j'utilise pour me donner des avertissements :

  1. Est-ce que je regrette que Bash ne dispose pas de tableaux en 2D (ou plus) ? Si oui, il est temps de réaliser que Bash n'est pas un grand langage de traitement de données.
  2. Est-ce que je fais plus de travail de préparation de données pour d'autres utilitaires que je ne fais fonctionner ces utilitaires ? Si oui, il est temps de réaliser que Bash n'est pas un excellent langage de traitement des données.
  3. Mon script devient-il tout simplement trop gros à gérer ? Si oui, il est important de réaliser que si Bash peut importer des bibliothèques script, il ne dispose pas d'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 dispose d'une énorme quantité de fonctionnalités intégrées (certains disent trop...).

Et la liste est encore longue. En fin de compte, lorsque vous travaillez plus dur pour faire fonctionner vos scripts que pour ajouter des fonctionnalités, il est temps de quitter Bash.

Supposons que vous ayez décidé de transférer votre travail vers Python. Si vos scripts Bash sont propres, la conversion initiale est assez simple. Il existe même plusieurs convertisseurs/traducteurs qui effectuent 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 de l'option subprocess (ou équivalent). Il y a plusieurs façons de faire cela, et jusqu'à la version 3.7, il fallait faire des efforts pour y arriver (3.7 improved subprocess.run() pour traiter tous les cas courants de manière autonome).

  2. Étonnamment, Python n'a pas d'utilitaire non bloquant standard indépendant de la plate-forme (avec délai d'attente) pour interroger le clavier (stdin). L'outil Bash read est un outil génial pour une interaction simple avec l'utilisateur. Mon utilisation la plus courante est d'afficher un spinner jusqu'à ce que l'utilisateur appuie sur une touche, tout en exécutant une fonction d'interrogation (à chaque étape du spinner) pour m'assurer que les choses fonctionnent toujours bien. Il s'agit d'un problème plus difficile qu'il n'y paraît à première vue, aussi je me contente souvent de faire un appel à Bash : Coûteux, mais il fait précisément ce dont j'ai besoin.

  3. Si vous développez sur un système embarqué ou avec des contraintes de mémoire, l'empreinte mémoire de Python peut être plusieurs fois supérieure à 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 n'est pas forcément 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 prend rapidement le dessus.

  5. Python possède le système de paquets le plus complet de la planète. Lorsque Bash devient un tant soit peu complexe, Python dispose probablement d'un paquetage qui transforme des pans entiers de Bash en un seul appel. Cependant, trouver le(s) bon(s) paquet(s) à utiliser est la partie la plus importante et la plus intimidante pour devenir un Pythonista. Heureusement, Google et StackExchange sont vos amis.

12voto

user1390860 Points 21

Si vous cherchez à bricoler un utilitaire rapide avec un minimum d'effort, bash est bon. Pour une enveloppe autour d'une application, bash est inestimable.

Tout ce qui peut vous amener à revenir sans cesse 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 lorsqu'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 tous des tâches personnalisées. Je n'ai rencontré que très peu de tâches de scripts shell pour lesquelles il existait déjà une solution librement disponible.

9voto

extraneon Points 13362

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

  • Scripting d'utilitaires en ligne de commande
  • Scripts dont l'exécution ne prend que peu de temps ; le démarrage de 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, on ne script mais on programme (éventuellement en Python).

0 votes

Mais python est un langage de script, donc on fait script. Si vous voulez de la rapidité, optez pour le C, le C++ ou le luajit, si vous voulez vous en tenir aux scripts.

4voto

Russell Borogove Points 8423

Dès que votre script bash doit faire quelque chose que bash ne supporte pas bien*, vous allez regretter de ne pas l'avoir fait en Python dès le départ.

* y compris "être lu et compris par quelqu'un d'autre".

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X