Besoin de quelque chose de plus rapide que «wc -l»

Pour un très gros fichier comme 1 Go, wc -lil s'avère être lent. Avons-nous un moyen plus rapide de calculer le nombre de sauts de ligne pour un fichier particulier?

Vous pouvez essayer d' écrire en C:

#include <unistd.h>
#include <stdio.h>
#include <string.h>
int main(){
  char buf[BUFSIZ];
  int nread;
  size_t nfound=0;
  while((nread=read(0, buf, BUFSIZ))>0){
    char const* p;
    for(p=buf; p=memchr(p,'\n',nread-(p-buf)); nfound++,p++) {;}
  }
  if(nread<0) { perror("Error"); return 1; }
  printf("%lu\n", nfound);
  return 0;
}

Enregistrer par exemple, wcl.ccompiler par exemple avec gcc wcl.c -O2 -o wclet exécuter avec

<yourFile ./wcl

Cela trouve des sauts de ligne saupoudrés dans un fichier de 1 Go sur mon système en environ 370 ms ( cycles répétés). (L'augmentation de la taille des tampons augmente légèrement le temps, ce qui est normal - BUFSIZ devrait être presque optimal). C'est très comparable aux ~ 380 ms dont je viens wc -l.

Mmaping me donne un meilleur temps d'environ 280 ms , mais il a bien sûr la limitation d'être limité aux fichiers réels (pas de FIFOS, pas d'entrée de terminal, etc.):

#include <stdio.h>
#include <string.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>
int main(){
  struct stat sbuf;
  if(fstat(0, &sbuf)<0){ perror("Can't stat stdin"); return 1; }

  char* buf = mmap(NULL, sbuf.st_size, PROT_READ, MAP_PRIVATE, 0/*stdin*/, 0/*offset*/);
  if(buf == MAP_FAILED){ perror("Mmap error"); return 1; } 

  size_t nread = sbuf.st_size, nfound=0;
  char const* p;
  for(p=buf; p=memchr(p,'\n',nread-(p-buf)); nfound++,p++) {;}

  printf("%lu\n", nfound);
  return 0;
}

J'ai créé mon fichier de test avec:

 $ dd if=/dev/zero of=file bs=1M count=1042 

et ajouté quelques nouvelles lignes de test avec:

 $ echo >> 1GB 

et un éditeur hexadécimal.

Vous pouvez améliorer la solution proposée par @pskocik en réduisant le nombre d'appels vers read. Il y a beaucoup d'appels pour lire des BUFSIZmorceaux à partir d'un fichier 1 Go. L'approche habituelle consiste à augmenter la taille du tampon:

• juste pour le plaisir, essayez d'augmenter la taille de la mémoire tampon d'un facteur 10. Ou 100. Sur mon Debian 7, BUFSIZc'est 8192. Avec le programme d'origine, c'est 120 000 opérations de lecture. Vous pouvez probablement vous permettre un tampon d'entrée de 1 Mo pour le réduire d'un facteur 100.
• pour une approche plus optimale, les applications peuvent allouer un tampon aussi grand que le fichier, nécessitant une seule opération de lecture. Cela fonctionne assez bien pour les "petits" fichiers (bien que certains lecteurs aient plus de 1 Go sur leur machine).
• enfin, vous pouvez expérimenter avec des E / S mappées en mémoire, qui gèrent l'allocation en tant que telle.

Lors de l'analyse comparative des différentes approches, vous pouvez garder à l'esprit que certains systèmes (tels que Linux) utilisent la plupart de la mémoire inutilisée de votre machine comme cache disque. Il y a quelque temps (il y a près de 20 ans, mentionné dans la vile FAQ ), j'étais perplexe devant les bons résultats inattendus d'un algorithme de pagination (pas très bon) que j'avais développé pour gérer les conditions de faible mémoire dans un éditeur de texte. On m'a expliqué qu'il fonctionnait rapidement parce que le programme fonctionnait à partir des tampons de mémoire utilisés pour lire le fichier, et que seulement si le fichier était relu ou écrit, il y aurait une différence de vitesse.

La même chose s'applique à mmap(dans un autre cas toujours sur ma liste de tâches à intégrer dans une FAQ, un développeur a rapporté de très bons résultats dans un scénario où le cache disque était la raison réelle de l'amélioration). L'élaboration de repères nécessite du temps et du soin pour analyser les raisons de la bonne (ou mauvaise) performance.

Lectures complémentaires:

• Est-il utile d'utiliser un tampon plus grand?
• mmap () vs lecture de blocs
• mmap, munmap - mappe ou démappe des fichiers ou des périphériques en mémoire (montre un exemple de programme)
• 13.7 E / S mappées en mémoire (bibliothèque GNU C)
• Comment purger les caches d'E / S disque sous Linux
• Comment vider les tampons et le cache sur un système Linux?