많은 양의 메모리를 사용하지 않고 큰 파일을 표시하는 가장 좋은 방법은 무엇입니까?

Question

Hex Workshop과 같은 많은 HEX 편집자는 비교적 작은 메모리 발자국을 유지하면서 대형 파일을 읽을 수도 있지만 여전히 스크롤을 매끄럽게 유지할 수 있습니다. 나는 이것을 달성하는 가장 좋은 방법을 찾고 있으므로 몇 가지 관련 질문이 있습니다.

Filestream 만 사용해야합니까?
- 버퍼링은 현재 추구 위치를 기반으로합니까? (뒤로 스크롤 할 때 일반적으로 페이지 폴이 될까요?)
- 내부적으로만 찾는 Filestream 용 래퍼를 만들면 FileStream이 올바르게 버퍼링하는 능력을 상하게합니까? (즉, 성능은 근처에 있더라도 반복적 인 추구에 크게 어려움을 겪을 것입니까? 버퍼링 알고리즘이나 디스크 스케줄러에 의존하여 성능을 높일 수 있습니까?)

메모리 매핑 된 I/O를 사용하는 것이 더 낫습니까? (나는 정말로 100MB까지 파일만을 기대합니다)
- 검색/점프/빠른 스크롤링에서 PageFaults가 눈에 띄는 성능 문제가 생길까요?

궁극적으로 데이터를 표시해야합니다. 전체 파일을 비트 맵으로 렌더링하고 변경시 이미지의 부분을 무효화해야합니까 (스크롤 컨트롤이 이미지에서 자체 페이징을하도록 함) 스크롤 이벤트에서 현재 디스플레이 영역을 생성해야합니까?

간단히 말해서, 데이터, 생성 된 이미지 또는 둘 다를 페이지를 표시합니까, 아니면 필요에 따라 얻거나 생성합니까? 이 작업에 가장 적합한 (WPF/.NET) 라이브러리/API 객체는 무엇입니까?

Answer 1

당신은 이미 대답을 가지고있는 것 같습니다.
이를위한 일반적인 솔루션은 사용 중입니다 메모리 매핑 파일 그리고 OS가 캐싱과 추구에 귀찮게하십시오.
먼저 가장 단순하고 가장 명백한 솔루션을 사용해보십시오. 만족도에 맞지 않으면 병목 현상을 최적화하십시오. 조기 최적화는 모든 악의 근원입니다.

Answer 2

100MB는 실제로 그렇게 크지 않습니다. 따라서 메모리에서는 아마도 새로운 기계에서 작동 할 것입니다.

그러나 시간이 지남에 따라 솔루션이 확장되지 않기를 원하지 않을 것입니다. 한계가 100MB라고 가정 한 순간 누군가가 200MB로 시도 할 것입니다. 그래서 나는 당신이 "찾는"경로를 가져가는 것이 좋습니다 - 그것이 일반적인 방법입니다.