find
일반 사용자로 예약된 명령을 실행하고 있습니다 .
내가 아는 전부는 리디렉션이 stdout/stderr 메시지가 터미널에 나타나는 것을 방지하는 것이라는 것입니다. 그렇다면 다양한 리디렉션 방법에 소요되는 시간이 다른 이유는 무엇입니까? tty의 쓰기 속도와 관련이 있습니까? 아니면 그 뒤에 다른 이유가 있습니까? 누구든지 이것을 이해하기 위해 올바른 방향을 알려줄 수 있습니까?
$ id
uid=1000(user1) gid=1000(user1) groups=1000(user1),1001(user2)
$time find /
<truncated output>
real 0m13.902s
user 0m0.197s
sys 0m0.448s
$ time find / >/dev/null
<truncated output>
real 0m0.298s
user 0m0.068s
sys 0m0.206s
$time find / 2> /dev/null
<truncated output>
real 0m13.279s
user 0m0.181s
sys 0m0.405s
$ time find / > /dev/null 2>&1
real 0m0.306s
user 0m0.109s
sys 0m0.174s
답변1
프로세스( find
)가 실제로 출력을 작성해야 하는 경우 해당 출력을 삭제하도록 지시하는 것보다 훨씬 더 오랜 시간이 걸립니다.
를 사용하면
find /
stdout과 stderr이 모두 터미널로 전송되며 이를 기록해야 합니다(예: 실제 결과 및 모든 권한 오류 등).를 사용하면
time find / >/dev/null
명령의 표준 출력이 제거되지만 여전히 오류(있는 경우)가 인쇄됩니다. 귀하의 결과를 보면, 합법적인 결과가 많고 오류가 거의 없습니다.를 사용하면
time find / 2> /dev/null
명령의 표준 출력이 여전히 터미널로 전송되지만 이제 stderr만 제거하면 됩니다. 파일 시스템을 통해 읽기 권한이 없다는 사실을 알게 되면 실제로 매우 빠른 속도가 될 수 있습니다.를 사용하면
time find / > /dev/null 2>&1
표준 출력을 삭제한 다음 표준 출력이 전송되는 위치로 표준 오류를 보냅니다. 즉, 둘 다 삭제합니다. 이것은 아무것도 출력하지 않으므로 모든 명령 중에서 가장 빠릅니다.
답변2
내가 아는 전부는 리디렉션이 stdout/stderr 메시지가 터미널에 나타나는 것을 방지하는 것이라는 것입니다.
아니요. 파일로 리디렉션할 수도 있습니다.
find / > ~/all-the-files
tty의 쓰기 속도와 어떤 관계가 있습니까?
어쨌든 그렇습니다.
어떤 종류의 터미널(Linux의 가상 콘솔, 로컬 xterm, SSH를 통해 연결된 터미널)을 사용하든 실제 터미널 에뮬레이터는 터미널에 인쇄된 모든 것을 그려야 하며, 이 경우 빠르게 스크롤됩니다. (여기서의 연결은 mosh
예외일 수 있습니다.)
네트워크 연결의 경우 전송 지연도 고려해야 하며, 데이터가 많은 경우 일부 데이터가 버퍼링될 수 있지만 전부는 아닐 수 있습니다. 무언가를 로 리디렉션하면 /dev/null
어디에도 저장되지 않고 그려지지 않습니다. 운영 체제가 실제로 디스크에 쓰기를 지연시키기 전에 메모리에 쓰기를 캐시할 수 있으므로 적당한 양의 데이터에 대해 파일로 리디렉션하는 것이 빠를 수도 있습니다. 대용량 데이터의 경우 디스크에 쓰는 것도 병목 현상이 발생할 수 있습니다. (또는 동기 I/O 모드에서 출력을 쓰는 프로세스를 관리하는 경우)
많은 출력을 수행하는 프로그램의 printf()
경우 데이터가 /dev/null
. 그렇지 않을 수도 있습니다 find
. I/O 속도나 시스템 호출 오버헤드로 인해 제한될 것이라고 생각합니다.
또한 동일한 디렉토리 트리에서 반복적으로 실행하는 경우 find
처음에는 디스크에서 읽어야 할 수 있으므로 처음에는 다른 것보다 속도가 느려질 수 있으며 그 이후에는 대부분의 데이터가 운영 체제에 의해 캐시됩니다. .