Precisa de algo que seja mais rápido que "wc -l"

Para um arquivo realmente grande como 1 GB, wc -lé lento. Temos uma maneira mais rápida de calcular o número de novas linhas para um arquivo específico?

Você pode tentar escrever em 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;
}

Salvar em, por exemplo, wcl.ccompilar, por exemplo, com gcc wcl.c -O2 -o wcle executar com

<yourFile ./wcl

Isso encontra novas linhas espalhadas em um arquivo de 1 GB no meu sistema em cerca de 370ms (execuções repetidas). (O aumento do tamanho do buffer aumenta um pouco o tempo, o que é esperado - o BUFSIZ deve estar próximo do ideal). Isso é muito comparável aos ~ 380ms que estou obtendo wc -l.

Mmaping me proporciona um tempo melhor de cerca de 280ms , mas é claro que tem a limitação de ser limitado a arquivos reais (sem FIFOS, sem entrada 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;
}

Eu criei meu arquivo de teste com:

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

e adicionou algumas linhas de teste com:

 $ echo >> 1GB 

e um editor hexadecimal.

Você pode aprimorar a solução sugerida pelo @pskocik reduzindo o número de chamadas para read. Existem muitas chamadas para ler BUFSIZblocos de um arquivo de 1 GB. A abordagem usual para fazer isso é aumentando o tamanho do buffer:

• apenas por diversão, tente aumentar o tamanho do buffer em um fator de 10. Ou 100. No meu Debian 7, BUFSIZé 8192. No programa original, são 120 mil operações de leitura. Provavelmente, você pode pagar um buffer de entrada de 1Mb para reduzi-lo por um fator de 100.
• para uma abordagem mais otimizada, os aplicativos podem alocar um buffer do tamanho do arquivo, exigindo uma única operação de leitura. Isso funciona bem o suficiente para arquivos "pequenos" (embora alguns leitores tenham mais de 1 GB na máquina).
• finalmente, você pode experimentar a E / S mapeada na memória, que lida com a alocação como tal.

Ao comparar as várias abordagens, lembre-se de que alguns sistemas (como o Linux) usam a maior parte da memória não utilizada da sua máquina como cache de disco. Há um tempo (quase 20 anos atrás, mencionado nas vil Perguntas frequentes ), fiquei surpreendido com resultados inesperadamente bons de um algoritmo de paginação (não muito bom) que eu havia desenvolvido para lidar com condições de pouca memória em um editor de texto. Foi-me explicado que funcionava rápido porque o programa estava funcionando com os buffers de memória usados ​​para ler o arquivo e que somente se o arquivo fosse relido ou gravado, haveria uma diferença na velocidade.

O mesmo se aplica a mmap(em outro caso ainda na minha lista de tarefas a incorporar em uma FAQ, um desenvolvedor relatou resultados muito bons em um cenário em que o cache do disco era o motivo real da melhoria). O desenvolvimento de benchmarks leva tempo e cuidado para analisar os motivos do bom (ou ruim) desempenho.

Leitura adicional:

• É útil usar um buffer maior?
• mmap () vs. blocos de leitura
• mmap, munmap - mapeia ou mapeia arquivos ou dispositivos na memória (mostra um programa de amostra)
• 13.7 E / S mapeada em memória (The GNU C Library)
• Como limpar caches de E / S de disco no Linux
• Como você esvazia os buffers e o cache em um sistema Linux?