Je l'ai jamais utilisé mais apparement le principe c'est de faire en sorte que le fichier soit accessible directement en mémoire sans passer par fopen(3) et compagnie et c'est donc à l'OS de gérer les I/O, grep(1) ne fait plus lui même les fread(3)/read(2) et c'est donc censé être plus rapide. Evidemment si le fichier change après l'appel de mmap(2) il risque d'y avoir des problèmes.
Donc pour répondre à la question "peut-on y perdre en performance ?", je pense que si mmap(2) n'est pas implémenté, oui puisqu'il y aura un appel à mmap(2) qui va échouer puis seulement aura lieu l'ouverture normale du fichier mais la perte de temps doit être marginale. Le principal problème c'est si le fichier est modifié après l'appel à mmap(2), soit
1/ le fichier garde la même taille
1.a/ la partie modifiée se situe après la partie qui est en train d'être traitée et donc tout va bien
1.b/ la partie modifiée se situe avant la partie qui est en train d'être traitée et le résultat ne sera pas forcément correct (change pas du cas où on utilise pas --mmap)
2/ le fichier change de taille
2.a/ le fichier grossi et on a pas accès à la partie qui a été ajoutée donc résultat incorrect
2.b/ le fichier rétreci et on a un problème (probablement un segfault) quand on essai d'accéder à la partie qui se trouve après la fin du fichier actuel
3/ ya un problème à un certains moment pendant la lecture du fichier et donc segfault quand grep essai d'accéder à la partie concernée
Pour plus de détails je suppose qu'aller voir les sources de grep(1) est le plus approprié.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: faire du grep plus rapidement!
Posté par Krunch (courriel, site web personnel) . En réponse au message [Terminal] faire du grep plus rapidement!. Évalué à 1.
Je l'ai jamais utilisé mais apparement le principe c'est de faire en sorte que le fichier soit accessible directement en mémoire sans passer par fopen(3) et compagnie et c'est donc à l'OS de gérer les I/O, grep(1) ne fait plus lui même les fread(3)/read(2) et c'est donc censé être plus rapide. Evidemment si le fichier change après l'appel de mmap(2) il risque d'y avoir des problèmes.
Donc pour répondre à la question "peut-on y perdre en performance ?", je pense que si mmap(2) n'est pas implémenté, oui puisqu'il y aura un appel à mmap(2) qui va échouer puis seulement aura lieu l'ouverture normale du fichier mais la perte de temps doit être marginale. Le principal problème c'est si le fichier est modifié après l'appel à mmap(2), soit
1/ le fichier garde la même taille
1.a/ la partie modifiée se situe après la partie qui est en train d'être traitée et donc tout va bien
1.b/ la partie modifiée se situe avant la partie qui est en train d'être traitée et le résultat ne sera pas forcément correct (change pas du cas où on utilise pas --mmap)
2/ le fichier change de taille
2.a/ le fichier grossi et on a pas accès à la partie qui a été ajoutée donc résultat incorrect
2.b/ le fichier rétreci et on a un problème (probablement un segfault) quand on essai d'accéder à la partie qui se trouve après la fin du fichier actuel
3/ ya un problème à un certains moment pendant la lecture du fichier et donc segfault quand grep essai d'accéder à la partie concernée
Pour plus de détails je suppose qu'aller voir les sources de grep(1) est le plus approprié.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.