Нужно что-то быстрее, чем «wc -l»

Для действительно большого файла, такого как 1 ГБ, wc -lбывает медленно. У нас есть более быстрый способ подсчета количества новых строк для конкретного файла?

Вы можете попробовать написать на 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;
}

Сохранить, например, wcl.cскомпилировать, например, с помощью gcc wcl.c -O2 -o wclи запустить с

<yourFile ./wcl

Это находит переводы строк в 1 Гб файла в моей системе примерно за 370 мс (повторные запуски ). (Увеличение размеров буфера немного увеличивает время, которое следует ожидать - BUFSIZ должен быть близок к оптимальному). Это очень сравнимо с ~ 380 мс, которые я получаю wc -l.

Mmaping дает мне лучшее время около 280 мс , но оно, конечно, имеет ограничение, ограниченное реальными файлами (без FIFOS, без ввода с терминала и т. Д.):

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

Я создал свой тестовый файл с:

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

и добавил несколько тестовых новых строк с:

 $ echo >> 1GB 

и шестнадцатеричный редактор.

Вы можете улучшить решение, предлагаемое @pskocik, уменьшив количество звонков до read. Существует много вызовов для чтения BUFSIZфрагментов из файла объемом 1 ГБ. Обычный подход к этому заключается в увеличении размера буфера:

• просто ради интереса попробуйте увеличить размер буфера в 10 или 100 раз. На моем Debian 7 BUFSIZэто 8192. С оригинальной программой это 120 тысяч операций чтения. Вы, вероятно, можете позволить себе входной буфер 1 Мб, чтобы уменьшить его в 100 раз.
• для более оптимального подхода приложения могут выделить буфер размером с файл, для чего требуется одна операция чтения. Это работает достаточно хорошо для «маленьких» файлов (хотя некоторые читатели имеют более 1 ГБ на своей машине).
• наконец, вы можете поэкспериментировать с отображаемым в память вводом / выводом, который обрабатывает распределение как таковое.

При тестировании различных подходов вы можете иметь в виду, что некоторые системы (например, Linux) используют большую часть неиспользуемой памяти вашей машины в качестве дискового кэша. Некоторое время назад (почти 20 лет назад, упомянутое в подлых FAQ ) я был озадачен неожиданно хорошими результатами (не очень хорошего) алгоритма подкачки, который я разработал для обработки условий нехватки памяти в текстовом редакторе. Мне объяснили, что он работает быстро, потому что программа работает из буферов памяти, используемых для чтения файла, и что только если файл будет перечитан или записан, будет разница в скорости.

То же самое относится и к mmap(в другом случае, все еще в моем списке дел для включения в FAQ, разработчик сообщил о очень хороших результатах в сценарии, где дисковый кеш был реальной причиной улучшения). Разработка эталонных тестов требует времени и усилий, чтобы проанализировать причины хорошей (или плохой) производительности.

Дальнейшее чтение:

• Полезно ли использовать больший буфер?
• mmap () против блоков чтения
• mmap, munmap - отображать или распаковывать файлы или устройства в память (показывает пример программы)
• 13.7 Отображение в памяти ввода-вывода (библиотека GNU C)
• Как очистить дисковые кэши ввода / вывода в Linux
• Как вы очищаете буферы и кеш в системе Linux?