Многие шестнадцатеричные редакторы, такие как Hex Workshop, могут даже читать файлы большого размера, сохраняя при этом сравнительно небольшой объем памяти, но при этом все равно продолжают плавную прокрутку. Я ищу лучший способ добиться этого, и поэтому у меня есть несколько связанных вопросов.
Должен ли я просто использовать FileStream?
- Является ли его буферизация на основе текущего местоположения поиска? (При прокрутке в обратном направлении обычно возникает ошибка страницы)
- Если я создам обертку для FileStream, которая использует только Seek для внутреннего использования, могу ли я нарушить способность FileStream правильно буферизовать? (то есть сильно ли пострадает производительность от повторного поиска, даже если запросы находятся рядом? Могу ли я полагаться на алгоритм буферизации или планировщик дисков для поддержания производительности?)
Было бы лучше использовать Memory-Mapped I / O? (Я действительно ожидаю, что файлы размером до 100 МБ)
- Могут ли страницы с ошибками поиска / перехода / быстрой прокрутки создавать заметные проблемы с производительностью?
В конечном итоге данные должны быть отображены. Должен ли я отображать весь файл как растровое изображение и делать недействительными части изображения при изменениях (позволяя элементу управления прокруткой выполнять свою собственную подкачку на изображении), или я просто должен генерировать текущую область отображения для событий прокрутки?
Короче говоря, нужно ли пейджировать Данные, сгенерированное изображение или и то, и другое, или я получаю / генерирую их по мере необходимости? Какие библиотеки (WPF / .Net) / объекты API лучше всего подходят для этой задачи?