저는 최근에 내장된 gnome-terminal, aterm, xterm, wterm, rxvt까지 다양한 터미널 에뮬레이터를 사용해 보았습니다. 제가 진행한 테스트는 다음과 같은 순서로 이루어졌습니다.
- 2개의 창으로 tmux 창 열기
- 왼쪽 창에는
grep a /et/c -r간단한 작업 과 같은 세부적이고 집중적인 작업이 표시됩니다.time seq -f 'blah blah %g' 100000 - 오른쪽 창은 100줄 이상의 코드가 있는 모든 파일을 열 수 있는 구문을 여는 vim 창이 됩니다.
왼쪽 창에 많은 출력이 인쇄되면 오른쪽 창은 매우 느리고 응답하지 않는 것처럼 보입니다. vim에서 스크롤을 시도했지만 변경하는 데 1-2초가 걸립니다. 왼쪽 창 을 누르려고 하면 CtrlC10초 이상 기다린 후 중지됩니다.
TTY에서 동일한 작업을 수행하면( CTRL++ ALT( F[1-6]) 누르기) 그런 일이 발생하지 않으며 두 창 모두 매우 반응이 좋습니다.
앤티앨리어싱 글꼴과 같은 일부 구성을 끄고, 음영을 끄고, 기본 설정을 사용하고, xmonad 및 openbox로 변경했지만 아무것도 변경되지 않았습니다.
결과는 터미널 간에 실제로 다르지 않지만 time seq -f 'blah blah %g' 100000특히 spitted Pane tmux(또는 다른 멀티플렉서)를 실행할 때 응답성이 다릅니다. 참고로 저는 이 모든 것을 최대화 모드에서 실행하고 있습니다.
프레임버퍼 터미널에 대해 읽었지만 그것이 어떻게 작동하는지, 어떻게 사용하여 터미널 에뮬레이터의 속도를 높일 수 있는지 잘 모르겠습니다.
그래서 내 질문은 터미널 에뮬레이터가 TTY보다 훨씬 느린 이유는 무엇입니까? TTY만큼 빠르게 만들 수 있나요? 어쩌면 하드웨어 가속이나 뭔가? 내가 아는 한 가지 사실은 최대화된 터미널 에뮬레이터를 실행할 때 X 서버의 해상도가 1920x1080이고 TTY를 실행할 때 해상도가 그보다 낮다는 것입니다. 하지만 이것이 성능에 어떤 영향을 미칠지는 잘 모르겠습니다.
답변1
GUI 터미널 에뮬레이터가 문자열을 인쇄할 때 문자열을 글꼴 코드 포인트로 변환하고 코드 포인트를 글꼴 렌더러로 보내고 비트맵을 가져와야 합니다.비트 블록 전송비트맵은 X 서버를 통해 표시됩니다.
글꼴 렌더러는 글리프를 검색하고 실행해야 합니다(트루타입/오픈타입 글꼴은프로그램글꼴 렌더러의 가상 머신 내에서 실행 중이신가요? ). 각 글리프가 실행될 때 글꼴 크기, 커닝(고정 폭 글꼴과 커닝이 잘 섞이지 않지만), 유니코드 준수에 대해 많은 결정이 내려지며 이는 아마도 sub의 래스터라이저를 사용하기 전일 수도 있습니다. - 픽셀 주소 지정. 그런 다음 터미널은 글꼴 래스터라이저에서 생성된 버퍼를 가져와 해당 비트블록을 올바른 위치로 전송해야 하며, 픽셀 형식 변환, 알파 채널(하위 픽셀 주소 지정용), 스크롤(포함)을 처리해야 합니다.더블리팅) 등
반대로 텍스트 모드에서 실행되는 가상 터미널에 문자열을 쓰는 경우(참고:아니요그래픽 콘솔)에는 이 문자열을 비디오 메모리에 쓰는 작업이 포함됩니다. '안녕하세요! '에는 13바이트(또는 색상이 필요한 경우 13개의 16비트 단어) 쓰기가 포함됩니다. X-Font Rasterizer 스트레칭 운동과 관절 깨기 운동을 시작하기 전에 작업이 완료되었습니다. 이것이 지난 수십 년 동안 텍스트 패턴이 그토록 중요한 이유입니다. 그것은매우빠른 구현. 스크롤도 생각보다 쉽습니다. 고대 Motorola 6845 기반 MDA 및 CGA에서도 단일 8비트 값을 레지스터에 기록하여 화면을 수직으로 스크롤할 수 있습니다(16비트... 너무 길 수도 있음). 화면 새로 고침회로나머지는 완료되었습니다. 실제로 프레임 버퍼의 시작 주소를 변경하고 있습니다.
그래픽 터미널을 텍스트 모드 터미널만큼 빠르게 만들 수는 없습니다.동일한컴퓨터. 하지만 걱정하지 마십시오. 일부 컴퓨터에는 최신 컴퓨터에서 볼 수 있는 가장 느린 그래픽 터미널보다 느린 텍스트 모드가 있습니다. 원래 IBM PC는 꽤 나빴습니다(DOS에는 소프트웨어 스크롤 기능이 있었습니다). 80286에서 처음으로 Minix 콘솔을 봤을 때 나는 스크롤(점프) 속도가 얼마나 빠른지 보고 놀랐습니다. 진행이 좋습니다.
업데이트: 터미널 속도를 높이는 방법
@퓨지세 가지가 언급되었습니다.그의 대답, 그러나 다음은 이에 대한 내 의견입니다.
- 터미널 크기를 줄이세요.내 터미널은 화면을 가득 채울 때까지 커지는 경향이 있으며, 가득 차면 속도가 느려집니다. 나는 그래픽 터미널에 화를 내고 짜증을 낸 다음 크기를 조정하면 모든 것이 좋아집니다. :)
- (@poige) 다른 터미널 에뮬레이터를 사용하세요.일부 최신 기능을 희생시키면서 엄청난 속도 향상을 얻을 수 있습니다.
xterm그리고rxvt매우 잘 작동하며 훌륭한 터미널 에뮬레이터가 있습니다. 나는 당신의 테스트가 "현대적인" 테스트보다 더 나은 성능을 발휘할 수 있다고 생각합니다. - (@poige) 확장 가능한 글꼴을 사용하지 마세요.1986이 터미널 반환을 요구할 수도 있지만 더 빠르다는 점은 부인할 수 없습니다. ;)
- (@poige) 단순화된 글꼴 래스터라이저앤티앨리어싱/하위 픽셀 주소 지정 및 힌트를 끄면 됩니다. 대부분은 환경 변수 재정의를 허용하므로 전역적으로 수행할 필요가 없습니다. 참고: 비트맵 글꼴을 선택하면 이는 의미가 없습니다.
- 이로 인해 가장 큰 피해가 발생합니다.사용하지 마세요(여러 창)
tmux— 두 개의 별도 터미널을 나란히 실행합니다. 두 개의 창을 표시할 때tmux커서를 많이 이동하려면 터미널 명령을 사용해야 합니다. 최신 터미널 라이브러리이지만매우빠르고 최적화가 뛰어나지만 여전히 원시 엔드포인트 대역폭에서 바이트를 훔칩니다. DEC VT 호환 터미널에서 커서를 임의의 행으로 이동하려면ESC [ row ; col H.ie 6-10바이트를 전송하십시오. 여러 터미널을 사용하면 작업을 분리하고 위치 지정, 최적화, 버퍼링 및 기타 모든 작업이 필요하지 않으며curses여러 CPU 코어를 더 잘 활용할 수 있습니다.
답변2
@Alexios가 모든 이유를 매우 잘 설명했지만 상대적으로 덜 고통스럽게 만드는 몇 가지 사항을 언급할 수 있습니다.
- 비트맵 글꼴을 사용하세요(
Terminal,Terminus-- 정말 멋지네요). - 앤티앨리어싱을 끄거나 최소한 고려하십시오.하위 픽셀 렌더링 없음,
- KDE 터미널 사용 —
konsole.
답변3
다른 그래픽 터미널 에뮬레이터보다 더 빠른 속도를 제공할 수 있는 반직관적인 트릭(비록 개방형/자유 유형 대신 비트맵 글꼴을 사용하는 간단한 터미널 에뮤보다 더 빠른 것은 코드의 더 간단한 터미널 오류처럼 들리지만), 고려해 보셨나요? Kitty 또는 Alacritty와 같은 OpenGL 터미널 에뮬레이터?
그들은 다른 터미널 에뮬레이터에 비해 속도를 사용하는 주요 이점 중 하나로 속도를 광고합니다.
나는 여러분이 일반 텍스트 모드 Linux 콘솔의 속도에 도달할 것이라고 기대하지 않습니다. 왜냐하면 2바이트(하나는 문자용이고 다른 하나는 전경색 및 배경색용)를 올바른 메모리 주소에 넣는 것은 너무 빠르기 때문입니다. GUI 터미널 에뮬레이터에 오면 아마도 가장 빠른 옵션일 것입니다.