Je présume que tu utilise l’implémentation GNU sed car il me semble (mais faut que je vérifie) que \s n’est pas standard...
Pour la performance, ce n’est pas lié qu’à la taille (qui reste un atout important au niveau du chargement et de l’exécution quand il y a de la charge) mais plus aux actions effectuées (et avec quels algorithmes.)
TR va parcourir le flot et faire des remplacements à la volée (du moins c’était aussi trivial avant de devoir prendre en compte les encodages multiple octets.)
SED doit séquentiellement parcourir les lignes du fichier en retenir celles qui correspondent puis appliquer le traitement demandé à la ligne. Cette approche est par nature forcément plus lente.
Il y a typiquement des choses que les petits utilitaires ne savent pas faire (par exemple substituer un caractère par un autre c’est bon, mais remplacer un mot par un autre non), et en général (presque tout) ce que tu ferais manuellement dans un éditeur de texte sied à Sed ...qui a été pensé comme pendant de scriptage de Ed/Ex. D’un autre côté, les enchaînements de pipe ne sont plus performants quand il y en a trop (j’ai compté une dégradation à partir de cinq sur une vieille bécane il y a longtemps, et puis de toute façon pour la gestion des erreurs on repassera) et surtout sur de gros volumes. Là, pouvoir faire dans le même programme plutôt que plusieurs processus qui s’attendent est mieux.
"It is seldom that liberty of any kind is lost all at once." ― David Hume
[^] # Re: Remarques
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au message Wrapper for ALSA recording of playback device. Évalué à 4.
Je présume que tu utilise l’implémentation GNU sed car il me semble (mais faut que je vérifie) que
\sn’est pas standard...Pour la performance, ce n’est pas lié qu’à la taille (qui reste un atout important au niveau du chargement et de l’exécution quand il y a de la charge) mais plus aux actions effectuées (et avec quels algorithmes.)
TR va parcourir le flot et faire des remplacements à la volée (du moins c’était aussi trivial avant de devoir prendre en compte les encodages multiple octets.)
SED doit séquentiellement parcourir les lignes du fichier en retenir celles qui correspondent puis appliquer le traitement demandé à la ligne. Cette approche est par nature forcément plus lente.
Il y a typiquement des choses que les petits utilitaires ne savent pas faire (par exemple substituer un caractère par un autre c’est bon, mais remplacer un mot par un autre non), et en général (presque tout) ce que tu ferais manuellement dans un éditeur de texte sied à Sed ...qui a été pensé comme pendant de scriptage de Ed/Ex. D’un autre côté, les enchaînements de pipe ne sont plus performants quand il y en a trop (j’ai compté une dégradation à partir de cinq sur une vieille bécane il y a longtemps, et puis de toute façon pour la gestion des erreurs on repassera) et surtout sur de gros volumes. Là, pouvoir faire dans le même programme plutôt que plusieurs processus qui s’attendent est mieux.
"It is seldom that liberty of any kind is lost all at once." ― David Hume