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

Question

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

2

Очень похожий вопрос также был задан здесь на SO, если вы заинтересованы, но, как мы увидим, принятый ответ на этот вопрос не всегда имеет место (и это никогда не касается моего шаблона использования приложения).

Код определения производительности состоит из конструктора FileStream (для открытия файла) и хэша SHA1 (реализация каркаса .Net). Код в значительной степени является версией С# того, что было задано в вопросе, который я связал с выше.

Случай 1: Приложение запускается либо в первый раз, либо в течение N-го времени, но с другим целевым файлом. Теперь приложению предлагается вычислить значения хэша в файлах, которые ранее не были доступны.

~ 50мс
80% конструктор FileStream
18% хэш-вычислений

Случай 2: Теперь приложение полностью завершено и снова запустилось, попросив вычислить хэш в тех же файлах:

~ 8ms
90% хэш-вычисление
8% конструктор FileStream

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

Итак, мой способ определения скорости - FileStream Constructor! Можно ли что-то сделать, чтобы ускорить этот вариант использования?

Спасибо.

P.S. Статистика была собрана с использованием профайлера JetBrains.

Alex K 02 нояб. 2009, в 21:38

Источник

1

Я вижу точно такое же поведение. Использование ReadAllBytes и вычисление хэша занимает короткое время, но может быть ужасно для памяти (в зависимости от размера файла). Поэтому я попытался передать FileStream в computehash MD5 ($ stream) и увидел совершенно неприемлемые результаты. Времена результата на порядки отличаются ...
thepip3r 28 март 2014, в 19:29
1

@ Алекс К.: Из исходного кода FileStream , что существуют тонны директив препроцессора, и даже в самых простых путях инициализация кажется довольно сложной. Возможно, вы захотите указать, с каким конкретным конструктором у вас возникли проблемы и как выглядит ваша среда, и, надеюсь, люди (намного) умнее меня могут вам помочь.
Griswald_911 03 авг. 2018, в 18:26
0

Вы правильно многопоточный? Да, количество шпинделей ограничено, но при доступе ко множеству небольших файлов один за другим вы можете проводить большую часть времени в ожидании данных, и вы МОЖЕТЕ ускорить это (или даже больше в SSD), перейдя в многопоточность. Не «экстремальный», а 2-3 потока МОЖЕТ помочь сократить время простоя.
TomTom 06 авг. 2018, в 15:36
0

Нужно больше информации. Как именно вы вызываете конструктор? Каковы ваши аргументы, и как они выглядят? Абсолютный путь или относительный путь? Вы планируете свою программу по сокращению / удалению JIT? Вы работаете в сценарии с ограниченным доверием или у вашего приложения полное доверие? Вы пытались открыть файл с помощью FileOptions.SequentialScan ? Вы пытались включить многоядерный Jit через ProfileOptimization.StartProfile ?
antiduh 06 авг. 2018, в 16:09
0

@antiduh все, что занимает 10 секунд, очевидно, не является функцией этих опций, а является ошибкой, которую я не ожидаю исправить.
Shine On You Crazy Diamond 07 авг. 2018, в 01:26
0

@DanielDonnelly - Вы отвечаете на вопрос, который не был задан. Вы не афиша, и афиша не указала, что у них были проблемы с 10-секундными задержками; их задержка 50 мс. Пожалуйста, не пытайтесь изменить тему вопроса другого автора; спросите свой вместо этого. Если вам сложно задать свой вопрос из-за низкой репутации, я могу предложить вам прочитать в справочном центре о том, как задавать продуктивные вопросы.
antiduh 07 авг. 2018, в 06:18

Показать ещё 4 комментария

Теги:

c#

performance

.net

windows

hard-drive

2 ответа

Ещё вопросы

Я вижу точно такое же поведение. Использование ReadAllBytes и вычисление хэша занимает короткое время, но может быть ужасно для памяти (в зависимости от размера файла). Поэтому я попытался передать FileStream в computehash MD5 ($ stream) и увидел совершенно неприемлемые результаты. Времена результата на порядки отличаются ...
@ Алекс К.: Из исходного кода FileStream , что существуют тонны директив препроцессора, и даже в самых простых путях инициализация кажется довольно сложной. Возможно, вы захотите указать, с каким конкретным конструктором у вас возникли проблемы и как выглядит ваша среда, и, надеюсь, люди (намного) умнее меня могут вам помочь.
Вы правильно многопоточный? Да, количество шпинделей ограничено, но при доступе ко множеству небольших файлов один за другим вы можете проводить большую часть времени в ожидании данных, и вы МОЖЕТЕ ускорить это (или даже больше в SSD), перейдя в многопоточность. Не «экстремальный», а 2-3 потока МОЖЕТ помочь сократить время простоя.
Нужно больше информации. Как именно вы вызываете конструктор? Каковы ваши аргументы, и как они выглядят? Абсолютный путь или относительный путь? Вы планируете свою программу по сокращению / удалению JIT? Вы работаете в сценарии с ограниченным доверием или у вашего приложения полное доверие? Вы пытались открыть файл с помощью FileOptions.SequentialScan ? Вы пытались включить многоядерный Jit через ProfileOptimization.StartProfile ?
@antiduh все, что занимает 10 секунд, очевидно, не является функцией этих опций, а является ошибкой, которую я не ожидаю исправить.
@DanielDonnelly - Вы отвечаете на вопрос, который не был задан. Вы не афиша, и афиша не указала, что у них были проблемы с 10-секундными задержками; их задержка 50 мс. Пожалуйста, не пытайтесь изменить тему вопроса другого автора; спросите свой вместо этого. Если вам сложно задать свой вопрос из-за низкой репутации, я могу предложить вам прочитать в справочном центре о том, как задавать продуктивные вопросы.

Joe · Answer 1 · 2009-11-02T19-12-00.000Z

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

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

Я не верю, что это так. Конструктор FileStream не читает весь файл, для этого вызывается хеш-функция. Но это конструктор, который занимает 80% времени.

Shay Erlichmen · Answer 2 · 2009-11-02T19-16-00.000Z

0

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

Shay Erlichmen 02 нояб. 2009, в 19:16

2

Разве использование конструктора, который принимает FileOptions делает это в потоке, если вы передаете его FileOptions.SequentialScan ? РЕДАКТИРОВАТЬ: да, он просматривает справочный источник, в котором параметр enum превращается в dwFlagsAndAttributes CreateFile , а значение enum равно 0x08000000 что совпадает со значением FILE_FLAG_SEQUENTIAL_SCAN
Scott Chamberlain 28 март 2014, в 21:30