Вообще заголовок новости должен был выглядеть как очередная серия рубрики "Удивительное - рядом", но я совершенно забыл - какая это уже была бы по счету серия. Ну да неважно.

Намедни пообщался со своим знакомым, заодно обсудили и мою тулзу. Высказал он вот такую мысль: "А для чего там будет столько разных алгоритмов ? Народ все равно будет пользовать либо стандартные CRC32 и MD5, либо выберет самый быстрый из тех, что есть в программе - MD4". Я, конечно, призадумался - резон в его словах есть.

Далее, как всегда, произошли события, никак не связанные с тем разговором. Решил я сравнить по скорости проверки Hasher и небезызвестный Total Commander.  Да, важное замечание. Тестовый файл представляет собой образ DVD9 и имеет размер 5.67 Gb. Так вот, результат получился удивительный - TC был быстрее, даже когда я отключил алгоритм хэширования и оставил только чтение файла.

Естественно, в природе так не бывает, и я понимал, что "как-то не так читаю". Небольшое расследование дало неожиданный (для меня) результат - все дело в размере блока памяти, который мы выделяем под чтение файла по частям. Я-то по наивности своей предполагал, что чем меньше обращений к диску, тем быстрее. Но "в действительности все совсем не так, как на самом деле". Оказалось, что оптимальный размер блока - 32 килобайта (sic !!!). При этом файл читался с диска с максимальной скоростью. В результате скорость чтения тут же поднялась до уровня TC.

И еще один интересный вывод. Для алгоритмов, скорость вычисления которых на данном процессоре больше, чем линейная скорость чтения файлов с диска, время проверки файла будет примерно одинаково. Что для "быстрого" MD4, что для гораздо более медленного SHA1. И это время практически не будет отличаться от... времени чтения файла с диска. Т.е. юзер сможет без проигрыша в скорости выбрать практически любой алгоритм.

Вот такая, блин, загогулина получилась.