16 진수 워크샵과 같은 많은 16 진수 편집기는 비교적 작은 메모리 사용 공간을 유지하면서 대용량 파일을 읽을 수 있지만 스크롤을 원활하게 유지합니다. 이를 달성하기위한 최선의 방법을 찾고 있는데 관련 질문이 몇 가지 있습니다.
그냥 FileStream을 사용해야합니까?
- 버퍼링은 현재 검색 위치를 기반으로합니까? (일반적으로 뒤로 스크롤 할 때 페이지 폴트가 발생합니까?)
- 내부적으로 Seek 만 사용하는 FileStream에 대한 래퍼를 만들면 제대로 버퍼링 할 수있는 FileStream의 기능이 손상됩니까? (즉, 탐색이 반복 되어도 성능이 계속 저하 될 수 있습니다. 성능을 높이기 위해 버퍼링 알고리즘이나 디스크 스케줄러를 사용할 수 있습니까?)
메모리 매핑 I/O를 사용하는 것이 좋습니까? (나는 단지 100MB 정도의 파일을 기대한다)
- 검색/점프/빠른 스크롤의 pagefault가 현저한 성능 문제를 일으킬 수 있습니까?
궁극적으로 데이터가 표시되어야합니다. 전체 파일을 비트 맵으로 렌더링하고 변경시 이미지의 일부분을 무효화해야합니까 (스크롤 컨트롤이 이미지에서 자체 페이징을 수행하도록해야합니까?) 또는 스크롤 이벤트에 현재 표시 영역을 생성해야합니까?
이렇게 짧게하면 데이터, 생성 된 이미지 또는 둘 모두를 페이지에 넣거나 필요한 경우 가져 오거나 생성합니까? 이 작업에 가장 적합한 (WPF/.Net) 라이브러리/API 개체는 무엇입니까?대용량 메모리를 사용하지 않고 대용량 파일을 표시하는 가장 좋은 방법은 무엇입니까?
2
A
답변
2
이미 답을 갖고있는 것 같습니다.
이 일반적인 해결책은 Memory Mapped files을 사용하고 OS가 캐싱 및 검색에 신경을 쓰도록합니다.
먼저 가장 단순하고 가장 명백한 해결책을 시도해보십시오. 만족스럽지 않으면 병목 현상을 최적화하십시오. Premature optimizations is the root of all evil.
1
100MB는 실제로 그렇게 크지 않습니다. 그래서 메모리에서 아마도 새로운 기계에서 작동합니다.
하지만 시간이 지남에 따라 솔루션이 확장되지 않기를 바랄 것입니다. 한도는 100MB라고 가정하면 200MB로 시도 할 것입니다. 그래서 나는 당신이 "찾는"길을 택할 것을 권한다 - 그것을하는 일반적인 방법이다.