Hai bisogno di qualcosa che sia più veloce di "wc -l"

Per un file molto grande come 1 GB wc -lsembra essere lento. Abbiamo un modo più veloce per calcolare il numero di newline per un determinato file?

Puoi provare a scrivere in 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;
}

Salva in eg wcl.c,, compila eg, con gcc wcl.c -O2 -o wcled esegui con

<yourFile ./wcl

Questo trova nuove righe cosparse in un file da 1 GB sul mio sistema in circa 370ms (ripetizioni). (L'aumento delle dimensioni del buffer aumenta leggermente il tempo, che è prevedibile - BUFSIZ dovrebbe essere vicino all'ottimale). Questo è molto paragonabile ai ~ 380ms che sto ricevendo wc -l.

Il Mmaping mi offre un tempo migliore di circa 280 ms , ma ovviamente ha il limite di essere limitato ai file reali (niente FIFOS, nessun input terminale, ecc.):

#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;
}

Ho creato il mio file di test con:

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

e aggiunto alcune nuove righe di test con:

 $ echo >> 1GB 

e un editor esadecimale.

Puoi migliorare la soluzione suggerita da @pskocik riducendo il numero di chiamate a read. Ci sono molte chiamate per leggere BUFSIZblocchi da un file da 1 GB. L'approccio abituale per farlo è aumentando la dimensione del buffer:

• solo per divertimento, prova ad aumentare la dimensione del buffer di un fattore di 10. O 100. Sul mio Debian 7, BUFSIZè 8192. Con il programma originale, sono 120 mila operazioni di lettura. Probabilmente puoi permetterti un buffer di input da 1 Mb per ridurlo di un fattore 100.
• per un approccio più ottimale, le applicazioni possono allocare un buffer grande quanto il file, richiedendo un'unica lettura. Funziona abbastanza bene per file "piccoli" (anche se alcuni lettori hanno più di 1 GB sul proprio computer).
• infine, è possibile sperimentare l'I / O mappato in memoria, che gestisce l'allocazione in quanto tale.

Quando si confrontano i vari approcci, è necessario tenere presente che alcuni sistemi (come Linux) utilizzano la maggior parte della memoria inutilizzata della macchina come cache del disco. Qualche tempo fa (quasi 20 anni fa, menzionato nella vile FAQ ), ero perplesso dai risultati sorprendentemente buoni di un algoritmo di paging (non molto buono) che avevo sviluppato per gestire le condizioni di memoria insufficiente in un editor di testo. Mi è stato spiegato che ha funzionato velocemente perché il programma funzionava dai buffer di memoria utilizzati per leggere il file e che solo se il file fosse stato riletto o scritto avrebbe avuto una differenza di velocità.

Lo stesso vale per mmap(in un altro caso ancora nella mia lista di cose da fare da incorporare in una FAQ, uno sviluppatore ha riportato ottimi risultati in uno scenario in cui la cache del disco è stata la vera ragione del miglioramento). Lo sviluppo di parametri di riferimento richiede tempo e cura per analizzare le ragioni della buona (o cattiva) performance.

Ulteriori letture:

• Utilizzare un buffer più grande è utile?
• mmap () vs. blocchi di lettura
• mmap, munmap - mappa o non mappare file o dispositivi in ​​memoria (mostra un programma di esempio)
• 13.7 I / O mappato in memoria (The GNU C Library)
• Come eliminare le cache di I / O del disco su Linux
• Come svuotare i buffer e la cache su un sistema Linux?