웹에서 본 글인데 흥미로워서 옮겨봅니다.

내용은 대용량 파일을 읽을 때 MSDN에서 권장하는 방식으로 하면(ReadFile의 기본 설정은 _FLAG_NO_BUFFERING을 사용하지 않음) 오히려 늦다는 것입니다.


----------------------------------------------------------------------

 

ReadFile()에서 FILE_FLAG_NO_BUFFERING 지정 하지 않는다 붉은 선

리니어(직선성)하게 접근 속도가 저하된다. FILE_FLAG_NO_BUFFERING을 지정한 경우에는 리니어한 속도저하의 경향은 보이지 않으므로 대용량 파일의 I/O 읽기를 할 때 Windows I/O 백버퍼링 알고리즘에 성능 버그가 있다가 생각된다. 요즘 시장에서는 TB 클래스의 저장 장치가 나오고 있으므로 치명적인 문제라고 생각

 

ReadFile()에서 FILE_FLAG_NO_BUFFERING 지정한다 녹색 선

2GiB 읽기에 12~13초대의 속도로 일정한 접근 속도를 자랑한다. FILE_FLAG_NO_BUFFERING를 출력 파일에 대해서 사용하면 에러가 발생한 적이 있어서 입력 파일에 대해서도 개발/테스트 환경에서는 에러가 일어나지 않았어도 다른 환경이랑 상황에 의해서는 에러가 발생할까 봐 회피했지만 지금의 상황에서는 사용하지 않으면 손해가 된다. 또한 네트웍 전송, CD-R, FAT USB 메모리로부터의 읽기를 시험해 보았지만 에러는 없었음

 

파일 맵핑에서 FILE_FLAG_NO_BUFFERING 지정한다 파란 선

2GiB의 읽기에 14초대의 구간과 20초대 구간이 존하하여 접근 속도는 시계열에 가까운 지형파를 그린다.


참고 http://d.hatena.ne.jp/wraith13/20080430/1209565632

 -------------------------------------------------------------------------------

 

 

FILE_FLAG_NO_BUFFERING 에 대한 것을 ‘Windows 인터널 5’(에이콘 출판)에서 찾아보면 이 옵션을 주면 파일에서 읽은 내용을 캐싱을 하지 않는다고 합니다. 문제는 작은 용량을 파일이라면 캐싱을 하는 것이 좋겠지만 대용량 파일의 경우 캐싱을 쓰고 지우기를 반복하는(캐싱하기에는 너무 큰 크기를 읽고 있으니) 쓸데 없는 짓을 하기 때문에 대용량 파일 I/O에서는 FILE_FLAG_NO_BUFFERING을 사용하는 쪽이 더 성능이 좋아진 것은 아닐까 생각합니다. 이 글을 적은 블로거도 저와 비슷한 생각을 하고 있더군요.

ReadFile의 버그라기 보다는 이 API가 만들어질 때는 저장 장치가 대용량이지 않았기 때문에 지금의 ReadFile API는 대용량 파일을 읽는 것에 대해서는 최적화 되어 있지 않은 것 같습니다. 곧 이런 부분도 현재 상황에 맞게 조정되지 않을까 생각합니다.

 

 

하드웨어의 변화는 예전이나 지금이나 빠르게 변하고 OS도 이에 맞추어서 변화를 합니다. 그래서 오래 전에 배웠던 것만을 생각하고 사용하면 생각지 않은 결과가 나옵니다. 특히 5년 전에 Windows API를 공부하고 그 이후에 하지 않았다면 Windows 7 이후의 OS에 대해서 공부를 하는 것이 좋습니다. 개인적으로는 Windows via C/C++ Windows 인터널 이라는 책을 추천합니다. 요즘 저는 Windows 인터널을 보고 있는 중인데 너무 두꺼워서 꽤 시간이 걸리듯합니다^^

저작자 표시
신고
by 흥배 2011.01.12 09:00