Le shell (quelque soit le shell) n'est pas performant, c'est mou que ça en peu plus (même dash) par conception. Pourtant on peut faire des programmes très performants en shell !
Les parties critiques peuvent être écris dans des langages différents (que ce soit du C ou un autre langage de script)
on peut très très très facilement faire du parallélisme poussé.
Il y a 2 grandes familles de parallélisme en shell qui sont très simples à faire.
Les pipelines, tout le monde les connais on les as tous déjà vu. Il y a des exemples plus hauts de programmes l'utilisant. On découpe un traitement en plusieurs étapes et chaque processus s'occupe d'une partie de ce traitement. On peut voir ça comme une programmation fonctionnelle. Chaque bout de programme est un filtre et a une entrée bien définie et une sortie bien définie (par exemple son entrée c'est des noms de fichiers et ça sortie c'est une sommes de contrôle un espace puis le nom du fichier).
Le parallélisme à la xargs (je connais pas le nom du paradigme), là il s'agit d'exécuter le traitement pleins de fois en parallèle. Il faut savoir qu'il n'y a pas que xargspour faire ça. find le fait aussi très bien avec le terminateur + à la place de ; en fin de commande. Il y a aussi gnu parallel, mais il est rarement installé.
L'énorme avantage de ces modes c'est qu'on ne lance pas des milliers de processus (notamment avec les pipes) ce qui est contre productif.
Si j'ai des conseils à donner sur les performances en shell, je conseil de regarder en priorité 3 choses :
le nombre de fork, lancer pleins de fois le même programme c'est très lourd, il faut généralement voir pour lui donner toutes les données d'un coup ou voir pour le lancer en arrière plan et pouvoir lui fournir les données au fur et à mesure
regarder les accès disque : utiliser des fichiers pour stocker des données interne au programme limite les performance (mais c'est des fois nécessaires vu que les pipes sont limités à 4Kio de données) et ajoute des la complexité (il ne faut pas de collision, il faut bien supprimer les fichiers à la fin du programme)
quand on utilise les pipe éviter comme la peste les traitement au milieu des pipelines qui nécessitent l'ensemble des données. Par exemple un sort va totalement détruire les performance des pipes parce qu'il va attendre d'avoir toutes les données avant de pouvoir commencer sont travail
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Un petit mot sur les performances
Posté par barmic . En réponse à la dépêche Revue des techniques de programmation en shell. Évalué à 10.
Le shell (quelque soit le shell) n'est pas performant, c'est mou que ça en peu plus (même dash) par conception. Pourtant on peut faire des programmes très performants en shell !
Il y a 2 grandes familles de parallélisme en shell qui sont très simples à faire.
Les pipelines, tout le monde les connais on les as tous déjà vu. Il y a des exemples plus hauts de programmes l'utilisant. On découpe un traitement en plusieurs étapes et chaque processus s'occupe d'une partie de ce traitement. On peut voir ça comme une programmation fonctionnelle. Chaque bout de programme est un filtre et a une entrée bien définie et une sortie bien définie (par exemple son entrée c'est des noms de fichiers et ça sortie c'est une sommes de contrôle un espace puis le nom du fichier).
Le parallélisme à la
xargs(je connais pas le nom du paradigme), là il s'agit d'exécuter le traitement pleins de fois en parallèle. Il faut savoir qu'il n'y a pas quexargspour faire ça.findle fait aussi très bien avec le terminateur+à la place de;en fin de commande. Il y a aussi gnu parallel, mais il est rarement installé.L'énorme avantage de ces modes c'est qu'on ne lance pas des milliers de processus (notamment avec les pipes) ce qui est contre productif.
Si j'ai des conseils à donner sur les performances en shell, je conseil de regarder en priorité 3 choses :
fork, lancer pleins de fois le même programme c'est très lourd, il faut généralement voir pour lui donner toutes les données d'un coup ou voir pour le lancer en arrière plan et pouvoir lui fournir les données au fur et à mesuresortva totalement détruire les performance des pipes parce qu'il va attendre d'avoir toutes les données avant de pouvoir commencer sont travailTous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)