Чому wc так повільно?

Чому утиліта wc така повільна?

Коли я запускаю його на великому файлі, він займає приблизно в 20 разів більше часу, ніж md5sum:

MyDesktop:/tmp$ dd if=/dev/zero bs=1024k count=1024 of=/tmp/bigfile
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.687094 s, 1.6 GB/s

MyDesktop:/tmp$ time wc /tmp/bigfile 
         0          0 1073741824 /tmp/bigfile

real    0m45.969s
user    0m45.424s
sys     0m0.424s

MyDesktop:/tmp$ time md5sum /tmp/bigfile 
cd573cfaace07e7949bc0c46028904ff  /tmp/bigfile

real    0m2.520s
user    0m2.196s
sys     0m0.316s

Це не просто дивна причина краю, оскільки файл заповнений нулями, я бачу однакову різницю в продуктивності, навіть якщо файл заповнений випадковими даними або є текстовим файлом.

(це на Ubuntu 13.04, 64 біт)

Тому я пішов до джерела, і схоже, що повільність у роботі з двобайтовими символами. По суті, для кожного прочитаного символу потрібно зателефонувати, mbrtowc()щоб спробувати перетворити його на широкий символ, тоді цей широкий символ перевіряється, щоб зрозуміти, чи це роздільник слів, роздільник рядків тощо.

Дійсно, якщо я зміню свою LANGзмінну локалі з стандартної en_US.UTF-8(UTF-8 - багатобайтовий набір символів) і встановлю її на " C" (простий однобайтовий набір символів), wcможе використовувати однобайтові оптимізації, що значно прискорює її, займає лише приблизно чверть, як раніше.

Крім того, він повинен перевіряти кожен символ лише якщо він виконує слово ( -w), довжину рядка ( -L) або символ ( -m). Якщо він займається лише підрахунком байтів та / або рядків, він може пропустити обробку широких символів і тоді він працює дуже швидко - швидше, ніж md5sum.

Я побіг через gprof, і функції, які використовуються для обробки символів мультібайтние ( mymbsinit(), mymbrtowc(), myiswprint(), і т.д.) займають близько 30% тільки у час виконання, а також код , який кроки через буфер є набагато більш складним , оскільки він повинен обробляти кроки змінного розміру через буфер для символів змінного розміру, а також набивати будь-які частково завершені символи, які перекидають буфер назад до початку буфера, щоб з ним можна було оброблятись наступного разу.

Тепер, коли я знаю, на що звернути увагу, я знайшов кілька публікацій, в яких згадується про повільність utf-8 з деякими утилітами:

/programming/13913014/grepping-a-huge-file-80gb-any-way-to-speed-it-up http://dtrace.org/blogs/brendan/2011/12/08 / 2000x-продуктивність-виграш /

Лише здогадка, але ти порівняєш яблука з апельсинами щодо того, що wcробиш проти того, що md5sumробиш.

Завдання md5sum

При md5sumобробці файлу він просто відкриває файл як потік, а потім починає запускати потік через функцію контрольної суми MD5, якій потрібно дуже мало пам'яті. Це по суті пов'язаний процесор і диск вводу / виводу.

завдання wc

Під час wcзапуску він робить набагато більше, ніж просто розбирає файл символу за один раз. Він повинен фактично проаналізувати структуру файлу, рядки за раз, визначаючи, де є межі між символами та чи є це межами слова чи ні.

Приклад

Подумайте про наступні рядки та про те, як кожен алгоритм повинен переходити через них під час їх розбору:

“Hello! Greg”
“Hello!Greg”
“Hello\nGreg”
“A.D.D.”
“Wow, how great!”
“wow     \n\n\n    great”
“it was a man-eating shark.”

Для MD5 він тривіально переміщається по цих рядках символом одночасно. Для wcнього , щоб вирішити , що це слово і лінії кордону і стежити за кількість входжень , що він бачить.

Додаткові обговорення в туалеті

Я знайшов цю проблему кодування з 2006 року, яка обговорює реалізацію wcв .NET. Труднощі досить очевидні, коли ви дивитесь на деякий псевдо-код, тому це може допомогти почати проливати світло на те, чому, wcздається, відбувається набагато повільніше, ніж інші операції.