Вам потрібно щось швидше, ніж "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фрагменти з файлу 1Gb. Звичайний підхід до цього полягає в збільшенні розміру буфера:

• просто для розваги, спробуйте збільшити розмір буфера в 10 разів. Або 100. На моєму Debian 7 BUFSIZце 8192. З оригінальною програмою це 120 тисяч операцій читання. Можливо, ви можете дозволити собі вхідний буфер 1 Мб, щоб зменшити його в 100 разів.
• для більш оптимального підходу програми можуть виділити буфер розміром з файлом, що вимагає однієї операції зчитування. Це працює досить добре для "невеликих" файлів (хоча деякі читачі мають більше 1 Гбіт на своїй машині).
• нарешті, ви зможете поекспериментувати зі вбудованим в пам'ять входом / виводом, який обробляє розподіл як таке.

Коли ви оцінюєте різні підходи, ви можете мати на увазі, що деякі системи (наприклад, Linux) використовують більшу частину невикористаної пам'яті вашого комп'ютера як кеш диска. Нещодавно (майже 20 років тому, що згадується в мерзенних FAQ ), мене здивували несподівано хороші результати (не дуже хорошого) алгоритму підкачки, який я розробив для обробки умов з низькою пам'яттю в текстовому редакторі. Мені було пояснено, що вона працює швидко, тому що програма працює з буферів пам'яті, які використовуються для читання файлу, і лише в тому випадку, якщо файл буде перечитаний або записаний, буде різниця у швидкості.

Це ж стосується mmap(в іншому випадку, все ще в моєму списку справ, щоб включити до FAQ, розробник повідомив про дуже хороші результати в сценарії, коли кеш-диск був фактичною причиною вдосконалення). Розробка тестів вимагає часу та турботи, щоб проаналізувати причини хорошої (або поганої) ефективності.

Подальше читання:

• Чи корисне використання більшого буфера?
• mmap () проти блоків читання
• mmap, munmap - карта чи скасування файлів чи пристроїв у пам'яті (показує зразок програми)
• 13.7 відображаються в пам'яті введення / виводу (Бібліотека GNU C)
• Як очистити кеші вводу / виводу диска в Linux
• Як ви спорожнюєте буфери та кеш в системі Linux?