Unix 환경의 고급 프로그래밍 3판, 3.9, I/O 효율성에서 나는 다음을 읽었습니다.
이 파일은 그림 3.5에 표시된 프로그램을 사용하여 읽으며 표준 출력은 /dev/null로 리디렉션됩니다. 이 테스트에 사용된 파일 시스템은 4,096바이트 블록을 갖춘 Linux ext4 파일 시스템이었습니다. (섹션 4.12에서 설명한 st_blksize 값은 4,096이었습니다.) 이는 4,096의 BUFFSIZE 주변에서 시작하는 여러 타이밍 측정에서 발생하는 시스템 시간 최소값을 보여줍니다.이 한도 이상으로 버퍼 크기를 늘리면 긍정적인 효과가 거의 없습니다.
제 질문은 왜 "이 한도 이상으로 버퍼 크기를 늘리면 긍정적인 효과가 거의 없습니다"입니다. 버퍼 크기를 늘리면 루프 수가 줄어들고 클럭 시간도 어느 정도 줄어들기 때문에 사용자 CPU 시간과 시스템 CPU 시간이 확실히 줄어들 것이라고 생각하는데, 그렇지 않습니까? 왜?
답변1
"이 한도 이상으로 버퍼 크기를 늘리는 것은 긍정적인 효과가 거의 없습니다"라는 말은 신뢰성이 없습니다.
게시된 코드는 실제로 얼마나 많은 바이트가 읽혀지고 각 루프 반복에서 기록되는지에 대한 표시를 제공하지 않습니다.파이프에서 읽기- 리디렉션 stdin. Linux PIPE_BUF값이 일반적으로 5120바이트라는 점을 고려하면 코드는 루프 반복당 소수의 킬로바이트를 읽고 쓸 수 있습니다.
버퍼 크기가 이 값보다 커지면 루프 반복당 이동된 실제 바이트 수는 변경되지 않으므로 버퍼 크기는 전혀 관련이 없습니다.
뿐만 아니라 테스트 방법은 완전히 문서화되지 않았습니다. 파일은 어떻게 프로세스에 전달되나요?에 출판된 도서 페이지https://www.dropbox.com/s/r67nacyrqb5ulww/apue_72-73.pdf?dl=0지정하지 않음 -별말씀을요. 테스트를 반복할 방법이 없습니다.우리는 테스트가 무엇인지 모르기 때문에.
또한 코드를 주의 깊게 읽어보세요.http://www.apuebook.com/src.3e.tar.gz많은 문제를 나타내며 비동기 신호를 호출하는 올바른 신호 처리기 대신 반환되는 것처럼 코딩됩니다 read().write()intssize_t안전하지 않음기능.
즉, 엉성한 코드와 엉성한 테스트입니다.