C'est vrai, et il est très rapide.
Pour le fun, j'ai fait des mesures comparant les diverses solutions proposées dans cette discussion avec le jeu de test de BufferBob (8 fichier de 1 à 8 Go avec chacun 200 "bouzin" dans la première ligne) dont voici les résultats:
Le grep qui lit tout le fichier va déjà trois fois plus vite que le sed -i initial qui lit et écrit tout le fichier.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9 méthode secondes gain sed-i 832.81 1 grep-echo 282.55 2.95 grep-m1-echo 8.15 102 dd-sed-dd 0.76 1095 dd-pipeline 0.58 1435 perl 0.58 1435 stdio 0.52 1601 syscalls 0.51 1632
Avec l'optimisation qui consiste à s'arrêter à la première occurrence de la chaîne recherchée, le programme va cent fois plus vite que le sed -i initial.
Le dd puis sed puis dd avec utilisation d'un fichier temporaire va plus de mille fois plus vite que le sed -i.
L'optimisation qui consiste à utiliser un pipeline plutôt que le fichier temporaire permet de gagner encore 30% supplémentaires (j'ai sous estimé ce gain en parlant de microsecondes, on gagne 42 ms par itération)..
Le script perl fait jeu égal avec le pipeline.
J'ai ajouté deux programmes en C pour évaluer la vitesse maximale possible, le premier utilise les entrées sorties de la bibliothèque standard C et il permet de gagner 11%. En utilisant directement les appels systèmes pour accéder aux fichier, on ne gagne que 2% supplémentaires.
Je laisse aux volontaires le codage en assembleur
Partager