Comme ton explication sur l'avantage de grapiller des perfs laisse déjà sous-entendre, les UUOC c'est mal uniquement lorsqu'on doit les passer à l'échelle et que le traitement est bien déterminé et figé. Si c'est du one shot, les UUOC (si on veut couper les cheuveux en 4, en fait certains cas prétendus comme étant des UUOC par certaines personnes) ne sont souvent en fait pas du tout U, car ils permettent de modifier la ligne de commande du pipeline plus rapidement (le fichier d'entrée est isolé au début et ne change pas si l'on remplace toute la fin de la ligne, donc y compris si l'on change la commande à appliquer sur le fichier).
(ya ptet dans certains shells moyen de faire une dérivation de stdin avec le nom de fichier en début de ligne, mais je préfère me contenter de cat que tout le monde connaît déjà et qui permet d'avoir une syntaxe de la commande ne dépendant pas du shell utilisé, quitte à consommer 100 mW.s supplémentaire et à attendre 3 ms de plus).
La notion de compromis vitesse de développement / performance est très classique. Certes dans certains cas on peut acquérir des réflexes qui permettent de faire tout aussi facilement la même chose en atteignant une efficacité absolue, mais ce n'est pas toujours le cas. Sinon on développerait sur x86 tout en langage machine :P (le langage d'assemblage ne permettant pas facilement de repérer des optimisations conviviales telles que le saut en plein milieu d'une intruction pour en obtenir une autre qui fait quelque chose qui n'a rien à voir, et autres joyeusetés). Et on ne ferait certainement jamais rien en shell, pour commencer.
[^] # Re: Perl caymieux
Posté par Guillaume Knispel . En réponse au journal [Droit d'auteur] À qui appartient N ?. Évalué à 5.
Comme ton explication sur l'avantage de grapiller des perfs laisse déjà sous-entendre, les UUOC c'est mal uniquement lorsqu'on doit les passer à l'échelle et que le traitement est bien déterminé et figé. Si c'est du one shot, les UUOC (si on veut couper les cheuveux en 4, en fait certains cas prétendus comme étant des UUOC par certaines personnes) ne sont souvent en fait pas du tout U, car ils permettent de modifier la ligne de commande du pipeline plus rapidement (le fichier d'entrée est isolé au début et ne change pas si l'on remplace toute la fin de la ligne, donc y compris si l'on change la commande à appliquer sur le fichier).
(ya ptet dans certains shells moyen de faire une dérivation de stdin avec le nom de fichier en début de ligne, mais je préfère me contenter de cat que tout le monde connaît déjà et qui permet d'avoir une syntaxe de la commande ne dépendant pas du shell utilisé, quitte à consommer 100 mW.s supplémentaire et à attendre 3 ms de plus).
La notion de compromis vitesse de développement / performance est très classique. Certes dans certains cas on peut acquérir des réflexes qui permettent de faire tout aussi facilement la même chose en atteignant une efficacité absolue, mais ce n'est pas toujours le cas. Sinon on développerait sur x86 tout en langage machine :P (le langage d'assemblage ne permettant pas facilement de repérer des optimisations conviviales telles que le saut en plein milieu d'une intruction pour en obtenir une autre qui fait quelque chose qui n'a rien à voir, et autres joyeusetés). Et on ne ferait certainement jamais rien en shell, pour commencer.