저는 Mint 19를 시나몬과 함께 실행하고 있는데 이는 모든 Linux 데스크톱 환경에서 공통적으로 발생하는 문제라고 생각합니다. 터미널 출력이 너무 많아서 터미널 창에 렌더링된 인쇄 문으로 인해 실제로 애플리케이션 속도가 느려지는 Python CLI 애플리케이션이 있습니다. 어리석은 질문: 터미널이 최소화되면 속도가 증가합니까(렌더링이 불필요하고 생략될 수 있음)?
답변1
성능을 향상시키려면 다음을 사용하여 명령을 실행하는 것이 좋습니다.
mycommand &>/dev/null
또는
mycommand &>~/mycommand.log
또 다른 방법도 좋습니다:
nohup mycommand
참고: 이것은 & 입니다아니요애플리케이션을 백그라운드에 배치하지만 표준 출력 및 표준 오류를 리디렉션합니다.
일부 벤치마크:
time hexdump HURRICANE\ SMITH\ -\ DON\ T\ LET\ IT\ DIE.mp3
real 0m17,525s
time hexdump HURRICANE\ SMITH\ -\ DON\ T\ LET\ IT\ DIE.mp3 &>/dev/null
real 0m0,226s
time hexdump HURRICANE\ SMITH\ -\ DON\ T\ LET\ IT\ DIE.mp3 &>/tmp/result.txt
real 0m0,244s
time nohup hexdump HURRICANE\ SMITH\ -\ DON\ T\ LET\ IT\ DIE.mp3
real 0m0,251s
터미널 출력이 실제 성능에 미치는 영향?
예를 들어...쉘 스크립트 내부에서...!
#!/bin/bash
date >/tmp/start.txt
hexdump HURRICANE\ SMITH\ -\ DON\ T\ LET\ IT\ DIE.mp3
date >/tmp/theend.txt
결과:
cat /tmp/start.txt
qua jan 9 14:49:08 -02 2019
cat /tmp/theend.txt
qua jan 9 14:49:25 -02 2019
첫 번째 예에서 볼 수 있듯이 인터프리터는 다음 명령을 실행하기 전에 모든 출력을 기다립니다. 이는 많은 상황에서 좋지 않을 수 있습니다.
이제 또 온다아니요터미널에 직접 데이터 쓰기...
#!/bin/bash
date >/tmp/start.txt
hexdump HURRICANE\ SMITH\ -\ DON\ T\ LET\ IT\ DIE.mp3 >/tmp/results.txt
date >/tmp/theend.txt
결과:
cat /tmp/start.txt
qua jan 9 14:52:02 -02 2019
cat /tmp/theend.txt
qua jan 9 14:52:02 -02 2019
두 번째 예에서는 스크립트가 빠르게 실행되며 모든 출력 데이터가 /tmp/result.txt에 이미 준비되어 있습니다.
창을 최소화하기만 하면 성능 향상이 거의 0이 됩니다. 왜냐하면 응용 프로그램이 창을 복원할 때 볼 수 있도록 최소화된 터미널에 로그를 계속 기록하고 있기 때문입니다.
성능에 영향을 주지 않고 로그 파일을 생성하지 않고 comamnd가 반환하는 내용을 읽으려면 다른 접근 방식을 시도해 보십시오.
yourcommand | less
답변2
터미널 에뮬레이터를 최소화해도 상당한(또는 눈에 띄는) 개선 효과를 얻을 가능성은 거의 없습니다.
가능한 한 빨리 입력을 읽고 처리하는 그래픽 터미널 에뮬레이터의 구성 요소입니다. 예를 들어, 내 컴퓨터에서 내가 선호하는 터미널 에뮬레이터는 약 10MB/s의 속도로 읽고, 구문 분석하고, 처리할 수 있습니다(물론 데이터 유형에 따라 다름).
터미널 에뮬레이터는 특정 입력을 처리한 후 즉시 화면을 업데이트하지 않으므로 참을 수 없을 정도로 느려질 수 있습니다. (리눅스 콘솔이 하는 일입니다. 프레임 버퍼를 사용하면 정말 견딜 수 없을 정도로 느리지만, 다른 VT로 전환하면 정말 빨라집니다.) 대조적으로, 그래픽 터미널 에뮬레이터는 초당 여러 번(아마도 20-60회) 디스플레이를 업데이트합니다. . 모두 적응형 프레임 속도를 구현해야 합니다. 즉, 페인팅에 너무 많은 시간이 걸리지 않도록 해야 합니다. 어떤 이유로든 그리기 속도가 느린 경우(예: 거대한 터미널 창, 가속되지 않는 그래픽 카드) 많은 CPU가 여전히 스트림을 읽는 데 사용될 수 있도록 그리기 빈도를 줄입니다.
일반적인 상황에서 화면을 초당 수십 번씩 다시 그리는 비용은 가능한 한 많은 데이터를 읽고 구문 분석하는 비용과 해당 데이터를 내보내는 애플리케이션의 비용에 비해 상당히 작아야 합니다.
애플리케이션 성능이 저하된다면 터미널 에뮬레이터 때문이 아닐 가능성이 높습니다.표현콘텐츠가 느립니다. 아마도 tty 라인이 커널과 터미널 에뮬레이터를 통과하기 때문일 것입니다.처리데이터가 최소화되더라도 데이터를 천천히 처리해야 합니다.