#1 Le 10/08/2024, à 22:42
- metalux
pipe ou substitution de processus?
Bonjour,
Qu'est-ce qui est le plus performant, un pipe ou une substitution de processus? Plusieurs critères de performance peuvent être pris en compte, la rapidité d'exécution mais aussi l'empreinte mémoire.
J'ai trouvé plusieurs sujet sur cette question sur les forums anglophones mais pas grand chose par ici. Et plus je lis, plus c'est flou.
Donc mieux vaut un :
ls ~ | grep Documentsou un
grep Documents <(ls ~)Ce n'est qu'un exemple d'illustration, ça peut s'appliquer à tous les cas ou une substitution de processus peut être faite.
Dernière modification par metalux (Le 11/08/2024, à 12:35)
Hors ligne
#2 Le 11/08/2024, à 09:46
- lann
Re : pipe ou substitution de processus?
Regarde le temps d'exécution :
time ls ~ | grep Documents
time grep Documents <(ls ~)<Modéré>
En ligne
#3 Le 11/08/2024, à 10:04
- diesel
Re : pipe ou substitution de processus?
jean-marie@jean-marie:~$ time (for ((i=1; i<1000; i++)); do ls ~ | grep Document;done)real 0m3,692s
user 0m2,192s
sys 0m3,728sjean-marie@jean-marie:~$ time (for ((i=1; i<1000; i++)); do grep Document <(ls ~);done)real 0m3,495s
user 0m2,193s
sys 0m3,829sJe te passe l'affichage des 999 lignes contenant "Documents".
Sauf à le faire des milliards de fois, je n'ai pas l'impression que ça fasse une grande différence.
Amicalement.
Jean-Marie
Dernière modification par diesel (Le 11/08/2024, à 10:06)
Je déteste qu'on cherche à me faire passer pour un con, j'y arrive déjà très bien tout seul.
Le mort, il sait pas qu'il est mort ; c'est pour les autres que c'est dur.................... Pour les cons, c'est pareil.
Hors ligne
#4 Le 11/08/2024, à 12:34
- metalux
Re : pipe ou substitution de processus?
J'ai bien essayé la commande time avant de poster mais le résultat n'est pas très fiable, la durée d'exécution diffère à chaque fois.
Je n'ai pas pensé faire une boucle, avec une valeur assez élevée, c'est encore variable mais ça me semble plus fiable, sur plusieurs essais, la substitution de processus a tout le temps terminé plus rapidement que le pipe (de 1m19 à 1m30 vs 1m36 à 1m40)
Il faudrait que je teste avec une valeur encore plus élevée et ce sur plusieurs essais mais ça semble confirmer que la substitution de processus est plus rapide.
La substitution de processus, et non substitution de commande comme j'ai indiqué dans le titre avant de le corriger, stocke le résultat de la commande dans un fichier temporaire (file descriptor) en mémoire ce qui n'est pas le cas du pipe qui exécuterait parallèlement les commandes et passerait au fur et à mesure la sortie de la 1ère commande à la seconde. Ça utiliserait un tampon et l'exécution de la 1ère commande serait limitée par celui-ci.
Donc un pipe serait plus rapide tant que la quantité de données produites par la 1ère commande reste inférieur au tampon. Dans le cas contraire, une substitution de processus serait plus rapide (boucle très longue, grep sur beaucoup de fichiers, etc...)
Je mets bien le subjonctif car il y a beaucoup d'informations contradictoires sur les forums. J'ai lu que la substitution de processus écrivait sur le disque, or si on fait le test avec un echo, on voit que le file descriptor /dev/fd/63 est écrit en mémoire et n'existe pas sur le disque pendant l'exécution de la commande.
Dernière modification par metalux (Le 11/08/2024, à 12:38)
Hors ligne
#5 Le 11/08/2024, à 13:27
- nany
Re : pipe ou substitution de processus?
Bonjour,
Je mets bien le subjonctif
Encore eût-il fallu que tu en misses. 
Je suppose que tu voulais parler du conditionnel. 
Hors ligne
#6 Le 11/08/2024, à 14:48
- metalux
Re : pipe ou substitution de processus?
Encore eût-il fallu que je me relise avant de poster.
Bon la grammaire et moi ça fait 2 visiblement.
Pour en revenir à ma question initiale, est-ce que ma compréhension de l'exécution de ces 2 commandes est juste?
Je me pose ce type de questions telle que celle-ci ou bien également mieux vaut une boucle while ou une boucle for? Ou un case/esac?
Il y a plusieurs façons d'arriver au résultat en scripting bash. Je ne me posais pas vraiment ce type de questions quand je scriptais il y a quelques années mais maintenant que j’essaie de m'y remettre un peu, je cherche à repartir sur des bases saines en optimisant un peu le code. Ce sont les limites de l'auto-didacte, il manque cruellement des bases pour comprendre comment s'exécute le code.
Hors ligne