Подтвердить что ты не робот

Файловый ввод-вывод с потоками - лучший размер буфера памяти

Я пишу небольшую библиотеку ввода-вывода, чтобы помочь с большим (хобби) проектом. Часть этой библиотеки выполняет различные функции в файле, который считывается/записывается через объект FileStream. На каждом проходе StreamReader.Read(...)

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

Мой главный вопрос: какой лучший размер буфера памяти использовать? Размышляя о макетах физического диска, я мог бы выбрать 2k, которые будут охватывать размер сектора компакт-дисков, и это краткий набор сектора жесткого диска размером 512 байт. Чем выше дерево абстракции, тем больше вы можете использовать буфер большего размера, который мог бы считывать весь кластер FAT за раз. Я понимаю, что на сегодняшнем ПК я мог бы использовать более голодный вариант памяти (например, несколько MiB), но затем я увеличиваю время между обновлениями пользовательского интерфейса, и пользователь воспринимает менее отзывчивое приложение.

В стороне, в конце концов, я надеюсь предоставить аналогичный интерфейс для файлов, размещенных на FTP/HTTP-серверах (через локальную сеть /fastish DSL). Каким будет лучший размер буфера памяти для этих (опять же, "наилучший вариант" между воспринимаемой реактивностью и эффективностью)?

4b9b3361

Ответ 1

Файлы уже буферизуются кешем файловой системы. Вам просто нужно выбрать размер буфера, который не заставит FileStream сделать собственный вызов Windows ReadFile() API, чтобы слишком часто заполнять буфер. Не уходите ниже килобайта, более 16 КБ - это потеря памяти и недружелюбие для CPU L1 cache (обычно 16 или 32 КБ данных).

4 KB - это традиционный выбор, хотя он будет точно охватывать страницу виртуальной памяти только когда-либо случайно. Трудно профилировать; вы в конечном итоге измеряете, сколько времени потребуется для чтения кэшированного файла. Который работает на скоростях RAM, 5 гигабайт/сек и выше, если данные доступны в кеше. Он будет в кэше во второй раз, когда вы запустите свой тест, и это не будет происходить в производственной среде слишком часто. Файловый ввод-вывод полностью доминирует в дисководе или NIC и медленный процесс медленный, копирование данных - это арахис. 4 KB будет работать нормально.

Ответ 2

Когда я обрабатываю файлы напрямую через объект потока, я обычно использую 4096 байт. Он кажется достаточно эффективным в нескольких областях ввода-вывода (локальная файловая система, LAN/SMB, сетевой поток и т.д.), Но я не профилировали его или что-то еще. Еще раз, когда я увидел несколько примеров, использующих этот размер, и он застрял в моей памяти. Это не значит, что это лучше всего.

Ответ 3

"Это зависит".

Вам нужно будет протестировать ваше приложение с разными размерами буфера, чтобы определить, что лучше. Вы не можете догадываться заранее.