FileStream очень медленный при холодном запуске приложения

... но с другим набором целевых файлов.

Ключевая фраза: ваше приложение не сможет использовать кеш файловой системы. Как это было во втором измерении. Информация о каталоге не может поступать из ОЗУ, потому что она еще не была прочитана, ОС всегда должна возвращаться к жесткому диску, а это медленно.

Только лучшее оборудование может ускорить его. 50 мс — это примерно стандартное время, необходимое для привода шпинделя, 20 мс — это минимальное время, на которое такие приводы могут работать. Время поиска головки считывателя является жестким механическим ограничением. Сегодня это легко превзойти, твердотельные накопители широко доступны и доступны по цене. Единственная проблема с ним в том, что, когда вы к нему привыкнете, вы никогда не отойдете назад :)

Файловая система и/или контроллер диска будут кэшировать недавно использованные файлы/сектора.

Шаг, определяющий скорость, — это чтение файла, а не создание объекта FileStream, и совершенно нормально, что второй запуск будет значительно быстрее, когда данные находятся в кэше.

Неправильное предложение, но это то, что я много сделал и получил наши анализы на 30% - 70% быстрее:

Кэширование

Напишите еще один фрагмент кода, который будет:

• перебрать все файлы;
• вычислить хэш; а также,
• сохраните его в другом файле index.

Теперь не вызывайте конструктор FileStream для вычисления хэша при запуске приложения. Вместо этого откройте (ожидаемо намного) меньший индексный файл и прочитайте из него предварительно вычисленный хэш.

Кроме того, если эти файлы являются файлами журналов и т. д., которые заново создаются каждый раз перед запуском вашего приложения, добавьте код в средство создания файлов, чтобы также обновить индексный файл с помощью хэша вновь созданного файла.

Таким образом, ваше приложение всегда сможет прочитать хэш только из индексного файла.

Я согласен с предложением @HansPassant использовать твердотельные накопители, чтобы ускорить чтение с диска. Этот ответ и его ответ являются бесплатными. Вы можете реализовать оба, чтобы максимизировать производительность.

Как было сказано ранее, файловая система имеет собственный механизм кэширования, который мешает вашим измерениям.

Однако конструктор FileStream выполняет несколько задач, которые в первый раз являются дорогостоящими и требуют доступа к файловой системе (поэтому то, чего может не быть в кеше данных). Для пояснения вы можете взглянуть на код и увидеть, что классы CompatibilitySwitches используются для обнаружения использования подфункций. Вместе с этим классом активно используется Reflection как напрямую (для доступа к текущей сборке), так и косвенно (для разделов, защищенных CAS, требуется ссылка безопасности). Движок Reflection имеет собственный кеш и требует доступа к файловой системе, когда его собственный кеш пуст.

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

Антивирусное программное обеспечение может решить агрессивно проверять определенные файлы изображений, например PNG, из-за известных уязвимостей декодирования. Такие проверки вносят дополнительное замедление и учитывают время в самом внешнем классе .NET, то есть в классе FileStream.

Профилирование с использованием собственных символов и/или отладки ядра должно дать вам больше информации.

Исходя из моего опыта, то, что вы описываете, не может быть смягчено, поскольку существует несколько скрытых уровней, которые мы не можем контролировать. В зависимости от вашего использования, которое мне сейчас не совсем понятно, вы можете превратить приложение в службу, поэтому вы можете быстрее обслуживать все последующие запросы. В качестве альтернативы вы можете объединить несколько запросов в один вызов, чтобы получить амортизированную сниженную стоимость.

Вам следует попробовать использовать собственный FILE_FLAG_SEQUENTIAL_SCAN, придется вызвать CreateFile, чтобы получить дескриптор и передать его FileStream