터미널 에뮬레이터 개요

우리 번역국의 몇 마디: 일반적으로 모든 사람이 최신 자료와 출판물을 번역하려고 노력하며 우리도 예외는 아닙니다. 하지만 단말기는 일주일에 한 번씩 업데이트되는 것이 아닙니다. 따라서 우리는 2018년 봄에 출판된 Antoine Beaupré의 기사를 번역했습니다. 현대 기준으로 볼 때 상당한 "연령"에도 불구하고 이 자료는 관련성을 전혀 잃지 않았습니다. 또한, 이 글은 원래 XNUMX개의 기사로 구성되어 있었는데, 이를 하나의 큰 게시물로 통합하기로 결정했습니다.

터미널은 컴퓨터 역사에서 특별한 위치를 차지하지만 최근 수십 년 동안 그래픽 인터페이스가 보편화되면서 명령줄과 함께 생존해야 했습니다. 터미널 에뮬레이터 스스로 교체했다 하드웨어 형제, 이는 천공 카드와 토글 스위치를 기반으로 한 시스템의 수정이었습니다. 최신 배포판에는 모든 모양과 색상의 다양한 터미널 에뮬레이터가 함께 제공됩니다. 많은 사람들이 작업 환경에서 제공되는 표준 터미널에 만족하지만 일부는 자신이 좋아하는 셸이나 텍스트 편집기를 실행하기 위해 완전히 이국적인 소프트웨어를 자랑스럽게 사용합니다. 그러나 이 기사에서 볼 수 있듯이 모든 터미널이 동일한 이미지로 생성된 것은 아닙니다. 기능, 크기 및 성능이 크게 다릅니다.

일부 터미널에는 완전히 놀라운 보안 허점이 있으며 대부분은 탭 인터페이스 지원에서 스크립팅에 이르기까지 완전히 다른 기능 세트를 가지고 있습니다. 비록 우리는 먼 과거에 터미널 에뮬레이터를 보았습니다., 이 기사는 독자들이 2018년에 어떤 단말기를 사용할지 결정하는 데 도움이 될 이전 자료의 업데이트입니다. 기사의 전반부는 기능을 비교하고 후반부는 성능을 평가합니다.

제가 검토한 터미널은 다음과 같습니다.

이 글을 쓰는 시점에는 Debian 9 또는 Fedora 27에서 출시할 수 있었던 안정적인 빌드로 제한되었기 때문에 최신 버전이 아닐 수도 있습니다. 유일한 예외는 Alacritty입니다. 이는 GPU 가속 터미널의 후손이며 이 작업을 위한 독특하고 새로운 언어인 Rust로 작성되었습니다. 리뷰에서 웹 터미널을 제외했습니다(다음에 있는 터미널 포함). 전자), 예비 테스트에서 성능이 매우 좋지 않았기 때문입니다.

유니코드 지원

유니코드 지원으로 테스트를 시작했습니다. 터미널의 첫 번째 테스트는 다음에서 유니코드 문자열을 표시하는 것이었습니다. 위키피디아 기사: “é, Δ, И, ק, م, ๗, あ, 叶, 葉 및 말.” 이 간단한 테스트는 단말기가 전 세계적으로 올바르게 작동할 수 있는지 여부를 보여줍니다. xterm 터미널에 아랍어 문자가 표시되지 않습니다. 멤 기본 구성:

기본적으로 xterm은 고전적인 "고정" 글꼴을 사용합니다. 여전히 같은 비키, "1997년 이후 상당한 유니코드 적용 범위"를 갖고 있습니다. 이 글꼴에는 문자가 빈 프레임으로 나타나게 하는 문제가 있으며 문자가 마침내 올바르게 표시되기 시작하는 것은 텍스트 글꼴이 20+ 포인트로 증가된 경우에만 발생합니다. 그러나 이 "수정"으로 인해 다른 유니코드 문자 표시가 중단됩니다.

이 스크린샷은 Fedora 27에서 찍은 것인데, 일부 이전 버전의 터미널(특히 mlterm)이 글꼴을 제대로 처리할 수 없었던 Debian 9보다 더 나은 결과를 제공했기 때문입니다. 다행히 이 문제는 이후 버전에서 수정되었습니다.

이제 xterm에 해당 행이 어떻게 표시되는지 확인하십시오. Mem 기호와 다음 셈어가 있음이 밝혀졌습니다. 코프 RTL 스타일 스크립트를 참조하십시오(오른쪽에서 왼쪽으로), 따라서 기술적으로는 오른쪽에서 왼쪽으로 표시되어야 합니다. Firefox 57과 같은 웹 브라우저는 위 줄을 올바르게 처리합니다. RTL 텍스트의 간단한 버전은 "사라" 히브리어로 (사라). 양방향 텍스트에 대한 Wiki 페이지 다음과 같이 말합니다:

“많은 컴퓨터 프로그램은 양방향 텍스트를 올바르게 표시할 수 없습니다. 예를 들어, 히브리어 이름 "Sarah"는 sin(ש)(오른쪽에 표시됨), resh(ר), 마지막으로 he(eh)(왼쪽에 표시됨)로 구성됩니다.

많은 터미널이 이 테스트에 실패합니다. Alacritty, VTE 파생 Gnome 및 XFCE 터미널, urxvt, st 및 xterm은 이름을 "Aras"로 쓴 것처럼 "Sara"를 역순으로 표시합니다.

양방향 텍스트의 또 다른 문제는 특히 RTL 및 LTR 텍스트를 혼합하는 경우 어떻게든 정렬해야 한다는 것입니다. RTL 스크립트는 터미널 창 오른쪽에서 실행되어야 하지만 기본적으로 LTR 영어로 설정된 터미널에서는 어떻게 해야 합니까? 대부분은 특별한 메커니즘이 없으며 모든 텍스트를 왼쪽으로 정렬합니다(Konsole 포함). 표준을 준수하고 해당 행을 오른쪽 정렬하는 pterm 및 mlterm은 예외입니다.

삽입 보호

제가 확인한 다음 중요한 기능은 삽입 방지 보호입니다. 다음과 같은 철자가 널리 알려져 있지만:

$ curl http://example.com/ | sh

코드 실행 푸시 명령은 신중하게 검사한 후에도 웹 브라우저에서 복사하여 붙여넣을 때 숨겨진 명령이 콘솔에 몰래 들어올 수 있다는 사실을 아는 사람이 거의 없습니다. 인증 사이트 Gianna Horna 명령이 얼마나 무해해 보이는지 훌륭하게 보여줍니다.

git clone git: //git.kernel.org/pub/scm/utils/kup/kup.git

Horn의 웹사이트에서 터미널에 붙여넣으면 매우 성가신 일이 됩니다.

git clone /dev/null;
    clear;
	echo -n "Hello ";
	whoami|tr -d 'n';
	echo -e '!nThat was a bad idea. Don'"'"'t copy code from websites you don'"'"'t trust! 
	Here'"'"'s the first line of your /etc/passwd: ';
	head -n1 /etc/passwd
	git clone git://git.kernel.org/pub/scm/utils/kup/kup.git

어떻게 작동하나요? 해당 블록에 악성코드가 포함되어 있습니다. , CSS를 사용하여 사용자 보기 밖으로 이동됩니다.

대괄호 붙여넣기 모드 이러한 공격을 무력화하도록 명확하게 설계되었습니다. 이 모드에서 터미널은 텍스트의 출처에 대해 쉘에 알리기 위해 붙여넣은 텍스트를 한 쌍의 특수 이스케이프 시퀀스로 묶습니다. 이는 붙여넣은 텍스트에 포함될 수 있는 특수 문자를 무시할 수 있음을 쉘에 알려줍니다. 유서 깊은 xterm으로 돌아가는 모든 터미널은 이 기능을 지원하지만 대괄호 모드로 붙여넣으려면 터미널에서 실행되는 셸이나 응용 프로그램의 지원이 필요합니다. 예를 들어, 다음을 사용하는 소프트웨어 GNU Readline (동일 Bash), 파일이 필요합니다 ~/.inputrc:

set enable-bracketed-paste on

불행하게도 Horn의 테스트 사이트에서는 텍스트 서식 자체를 통해 이 보호를 우회하고 대괄호 모드를 조기에 적용하는 방법도 보여줍니다. 이는 일부 터미널이 자신을 추가하기 전에 이스케이프 시퀀스를 올바르게 필터링하지 않기 때문에 작동합니다. 예를 들어, 저는 올바른 구성을 사용해도 Konsole 테스트를 성공적으로 완료할 수 없었습니다. .inputrc 파일. 이는 지원되지 않는 응용 프로그램이나 잘못 구성된 셸로 인해 시스템 구성이 쉽게 손상될 수 있음을 의미합니다. 이는 신중한 구성 작업이 일반적이지 않은 원격 서버에 로그인할 때 특히 위험하며, 특히 이러한 원격 시스템이 많은 경우 더욱 그렇습니다.

이 문제에 대한 좋은 해결책은 터미널용 붙여넣기 확인 플러그인입니다. urxvt, 개행이 포함된 텍스트를 삽입할 수 있는 권한을 요청합니다. Horn이 설명한 텍스트 공격에 대해 더 안전한 옵션을 찾지 못했습니다.

탭 및 프로필

현재 인기 있는 기능은 탭 인터페이스 지원입니다. 이를 여러 다른 터미널을 포함하는 하나의 터미널 창으로 정의하겠습니다. 이 기능은 터미널마다 다르며 기존 xterm 터미널은 탭을 전혀 지원하지 않지만 Xfce 터미널, GNOME 터미널 및 Konsole과 같은 최신 터미널 구현에는 이 기능이 있습니다. Urxvt는 탭도 지원하지만 플러그인을 사용하는 경우에만 가능합니다. 그러나 탭 지원 자체 측면에서는 Terminator가 확실한 선두주자입니다. Terminator는 탭을 지원할 뿐만 아니라 터미널을 어떤 순서로든 정렬할 수도 있습니다(아래 이미지 참조).

Terminator의 또 다른 기능은 이러한 탭을 함께 "그룹화"하고 동시에 여러 터미널에 동일한 키 입력을 보내는 기능으로, 여러 서버에서 동시에 대량 작업을 수행하기 위한 조잡한 도구를 제공합니다. 비슷한 기능이 Konsole에도 구현되어 있습니다. 다른 단말기에서 이 기능을 사용하려면 다음과 같은 타사 소프트웨어를 사용해야 합니다. 클러스터 SSH, 엑스랙스 또는 tmux.

탭은 프로필과 함께 사용할 때 특히 잘 작동합니다. 예를 들어 하나의 탭은 이메일용, 다른 탭은 채팅용 등으로 사용할 수 있습니다. 이는 Konsole 터미널과 GNOME 터미널에서 잘 지원됩니다. 둘 다 각 탭이 자동으로 자체 프로필을 시작할 수 있습니다. 터미네이터는 프로필도 지원하지만 특정 탭을 열 때 특정 프로그램을 자동으로 실행하는 방법을 찾지 못했습니다. 다른 단말기에는 '프로파일'이라는 개념이 전혀 없습니다.

러플

이 기사의 첫 번째 부분에서 마지막으로 다룰 내용은 터미널의 모양입니다. 예를 들어 GNOME, Xfce 및 urxvt는 투명성을 지원하지만 최근 배경 이미지에 대한 지원을 중단하여 일부 사용자는 터미널로 전환해야 했습니다. Tilix. 개인적으로 만족스럽고 간편해요 외부 리소스urxvt의 기본 배경색 세트를 설정합니다. 그러나 표준이 아닌 색상 테마도 문제를 일으킬 수 있습니다. 예를 들어, 솔라 라이즈 드 효과가 없다 애플리케이션으로 htop и IP트라프, 이미 자신만의 색상을 사용하고 있기 때문입니다.

기존 VT100 터미널 색상을 지원하지 않았으며 새로운 색상은 종종 256색 팔레트로 제한되었습니다. 터미널 스타일을 지정하는 고급 사용자의 경우 복잡한 방식으로 쉘 프롬프트나 상태 표시줄이 성가신 제한 사항이 될 수 있습니다. 요점 "트루 컬러"를 지원하는 터미널을 추적합니다. 내 테스트에서는 st, Alacritty 및 VTE 기반 터미널이 트루 컬러를 완벽하게 지원하는 것으로 확인되었습니다. 다른 터미널은 이와 관련하여 그다지 좋은 결과를 내지 못하며 실제로 256색도 표시하지 않습니다. 아래에서 GNOME 터미널의 트루 컬러 지원, st 및 xterm(256 색상 팔레트로 이 작업을 훌륭하게 수행)과 테스트에 실패할 뿐만 아니라 그 대신 일부 깜박이는 문자를 표시하는 urxvt 간의 차이점을 볼 수 있습니다.

일부 터미널에서는 URL 패턴에 대한 텍스트를 분석하여 링크를 클릭할 수 있도록 만듭니다. 이는 모든 VTE 파생 터미널에 적용되는 반면, urxvt에는 클릭이나 키보드 단축키를 사용하여 URL을 변환하는 특수 플러그인이 필요합니다. 기타 터미널 다른 방법으로 표시 URL을 테스트했습니다.

마지막으로 터미널의 새로운 추세는 스크롤 버퍼의 선택성입니다. 예를 들어 st에는 스크롤 버퍼가 없습니다. 사용자가 tmux와 같은 터미널 멀티플렉서를 사용할 것이라고 가정합니다. GNU 화면.

Alacritty에는 백스크롤 버퍼도 부족하지만 곧 추가될 예정입니다 이 주제에 대한 사용자의 "광범위한 피드백"으로 인해 지원됩니다. 이러한 신생 기업 외에도 내가 테스트한 모든 터미널은 역방향 스크롤을 지원합니다.

부분합

자료의 두 번째 부분에서 (원본에는 두 개의 다른 기사가 있었습니다. 레인) 성능, 메모리 사용량 및 대기 시간을 비교해 보겠습니다. 그러나 문제의 일부 터미널에는 심각한 단점이 있음을 이미 알 수 있습니다. 예를 들어 RTL 스크립트를 정기적으로 사용하는 사용자는 유사한 작업을 다른 사람보다 더 잘 처리할 수 있는 mlterm 및 pterm을 고려할 수 있습니다. Konsole도 좋은 성능을 보였습니다. RTL 스크립트를 사용하지 않는 사용자는 다른 것을 선택할 수 있습니다.

악성 코드 삽입에 대한 보호 측면에서 urxvt는 이러한 유형의 공격에 대한 특별한 보호 구현으로 인해 눈에 띄는데, 이는 확실히 편리한 것 같습니다. 부가 기능을 찾는 사람들에게는 Konsole을 살펴볼 가치가 있습니다. 마지막으로 VTE는 색상 지원, URL 인식 등을 보장하는 탁월한 터미널 기반이라는 점은 주목할 가치가 있습니다. 얼핏 보면 여러분이 선호하는 환경에 기본으로 제공되는 터미널이 모든 요구 사항을 충족할 수도 있지만, 성능을 이해할 때까지는 이 질문을 열어두겠습니다.

우리는 대화를 계속합니다

일반적으로 터미널의 성능 자체는 터무니없는 문제처럼 보일 수 있지만, 알고 보면 이러한 기본 유형의 소프트웨어에 비해 일부 터미널은 놀라울 정도로 높은 대기 시간을 나타냅니다. 또한 다음에는 전통적으로 "속도"라고 불리는 것(실제로 이는 스크롤 속도)과 터미널의 메모리 소비(수십 년 전만큼 오늘날에는 중요하지 않다는 주의 사항 포함)를 살펴보겠습니다.

지연

단말기 성능을 면밀히 조사한 결과, 이와 관련하여 가장 중요한 매개 변수는 대기 시간(핑)이라는 결론에 도달했습니다. 그의 기사에서 “우리는 즐겁게 인쇄합니다” Pavel Fatin은 다양한 텍스트 편집기의 대기 시간을 살펴보고 이와 관련하여 터미널이 가장 빠른 텍스트 편집기보다 느릴 수 있음을 암시했습니다. 궁극적으로 제가 자체 테스트를 실행하고 이 기사를 작성하게 된 것은 바로 이 힌트였습니다.

그러면 대기 시간이란 무엇이며 왜 그렇게 중요한가요? 그의 기사에서 Fatin은 이를 "키를 누르는 것과 해당 화면 업데이트 사이의 지연"으로 정의하고 다음과 같이 인용했습니다. "인간-컴퓨터 상호작용 가이드", "컴퓨터 디스플레이의 시각적 피드백 지연은 타이피스트의 행동과 만족도에 중요한 영향을 미칩니다."

Fatin은 이 핑이 단순한 만족보다 더 깊은 결과를 가져온다고 설명합니다. "타이핑 속도가 느려지고 오류가 더 많이 발생하며 눈과 근육의 긴장이 증가합니다." 즉, 지연이 크면 뇌에 추가적인 인지 부하가 ​​발생하므로 오타가 발생하고 코드 품질이 저하될 수 있습니다. 그러나 더 나쁜 것은 핑이 "눈과 근육의 피로를 증가시킨다"는 것입니다. 직업상 부상의 발달 앞으로는 (분명히 저자는 눈, 등, 팔, 물론 시력 근육의 문제를 의미합니다. 레인) 반복적인 스트레스로 인해

이러한 효과 중 일부는 오랫동안 알려져 왔으며 그 결과는 다음과 같습니다. 연구1976년에 Ergonomics 저널에 게재된 에서는 100밀리초의 지연이 "타이핑 속도를 크게 저하시킨다"고 밝혔습니다. 최근에는 그놈 사용자 가이드가 소개되었습니다. 허용 가능한 응답 시간 10밀리초 안에, 더 나아가면 마이크로 소프트 연구 1밀리초가 이상적이라는 것을 보여줍니다.

Fatin은 텍스트 편집기에서 테스트를 수행했습니다. 그는 휴대용 악기를 만들었습니다. 타이포미터, 터미널 에뮬레이터에서 핑을 테스트하는 데 사용되었습니다. 테스트는 시뮬레이션 모드에서 수행되었습니다. 실제로는 입력(키보드, USB 컨트롤러 등) 및 출력(비디오 카드 버퍼, 모니터) 대기 시간을 모두 고려해야 합니다. Fatin에 따르면 일반적인 구성에서는 약 20ms입니다. 게임 장비가 있다면 단 3밀리초 안에 이를 달성할 수 있습니다. 우리는 이미 그렇게 빠른 하드웨어를 갖고 있기 때문에 애플리케이션이 자체적으로 대기 시간을 추가할 필요가 없습니다. Fatin의 목표는 애플리케이션 대기 시간을 1밀리초로 늘리거나 심지어 전화 없이 전화 걸기를 달성하는 것입니다. 측정 가능한 지연, 어떻게 IntelliJ IDEA 15.

내 실험이 그의 테스트와 일치한다는 것을 보여주기 위해 내 측정 결과와 Fatin의 결과 중 일부는 다음과 같습니다.

저를 가장 먼저 놀라게 한 것은 xterm 및 mlterm과 같은 오래된 프로그램의 더 나은 응답 시간이었습니다. 최악의 레지스터 대기 시간(2,4ms)으로 가장 빠른 최신 터미널(st의 경우 10,6ms)보다 더 나은 성능을 발휘했습니다. 최신 터미널은 10밀리초 임계값 아래로 떨어지지 않습니다. 특히 Alacritty는 2017년 첫 번째 검토 이후 점수가 향상되었지만 "사용 가능한 가장 빠른 터미널 에뮬레이터"라는 주장을 충족하지 못했습니다. 실제로 프로젝트 작성자는 상황을 인지하고 있다 디스플레이를 개선하기 위해 노력하고 있습니다. 또한 GTK3을 사용하는 Vim은 GTK2에 비해 속도가 훨씬 느리다는 점에 유의해야 합니다. 이것으로부터 우리는 GTK3가 추가 대기 시간을 생성하고 이는 이를 사용하는 다른 모든 터미널(Terminator, Xfce4 터미널 및 GNOME 터미널)에 반영된다는 결론을 내릴 수 있습니다.

그러나 그 차이는 눈으로 눈에 띄지 않을 수도 있습니다. Fatin이 설명했듯이 "지연이 당신에게 영향을 미치기 위해 지연을 인식할 필요는 없습니다." Fatin은 또한 표준 편차에 대해 경고합니다. "지연 시간(지터)의 교란은 예측 불가능성으로 인해 추가적인 스트레스를 발생시킵니다."

위의 그래프는 순수 Debian 9(stretch)에서 찍은 것입니다. i3 창 관리자. 이 환경은 대기 시간 테스트에서 최상의 결과를 생성합니다. 결과적으로 GNOME은 모든 측정에 대해 20ms의 추가 핑을 생성합니다. 이에 대한 가능한 설명은 입력 이벤트를 동기식으로 처리하는 프로그램이 있다는 것입니다. Fatin은 그러한 경우에 대한 예를 제시합니다. 워크 래브, 모든 입력 이벤트를 동기식으로 처리하여 지연을 추가합니다. 기본적으로 그놈에는 창 관리자도 함께 제공됩니다. 속삭임, 이는 핑에 영향을 미치고 최소 8밀리초의 대기 시간을 추가하는 추가 버퍼링 계층을 생성합니다.

스크롤 속도

다음 테스트는 화면에 많은 양의 텍스트를 표시하면서 터미널이 페이지를 얼마나 빨리 스크롤할 수 있는지를 측정하는 전통적인 "속도" 또는 "대역폭" 테스트입니다. 테스트 메커니즘은 다양합니다. 원래 테스트는 단순히 seq 명령을 사용하여 동일한 텍스트 문자열을 생성하는 것이었습니다. 다른 테스트로는 Thomas E. Dickey(xterm 관리자) 테스트가 있습니다. terminfo.src 파일이 다운로드되었습니다.. 단말기 성능에 대한 또 다른 리뷰에서 덴 루 cat을 사용하여 터미널에 출력되는 무작위 바이트의 base32 인코딩 문자열을 사용합니다. Luu는 이러한 테스트를 "상상할 수 있을 만큼 쓸모없는 벤치마크"라고 생각하고 대신 터미널 응답을 기본 측정 기준으로 사용할 것을 제안합니다. Dickey는 또한 자신의 테스트가 오해의 소지가 있다고 말합니다. 그러나 두 저자 모두 터미널 창 대역폭이 문제가 될 수 있음을 인정합니다. Luu는 대용량 파일을 표시할 때 Emacs Eshell이 ​​멈추는 것을 발견했고 Dickey는 xtrerm의 시각적 부진을 없애기 위해 터미널을 최적화했습니다. 따라서 이 테스트에는 여전히 장점이 있지만 렌더링 프로세스가 터미널마다 매우 다르기 때문에 다른 매개변수를 테스트하기 위한 테스트 구성 요소로 사용할 수도 있습니다.

여기서 우리는 rxvt와 st가 경쟁에서 앞서 나가는 것을 볼 수 있으며, 성능에 중점을 두고 설계된 훨씬 더 새로운 Alacritty가 뒤따릅니다. 다음은 거의 두 배 빠른 Xfce(VTE 제품군)와 Konsole입니다. 마지막은 rxvt보다 XNUMX배 느린 xterm입니다. 테스트 중에 xterm도 잔물결이 심해서 같은 줄이라 하더라도 전달되는 텍스트를 보기 어렵게 만들었습니다. Konsole은 빠르지만 때때로 까다로웠습니다. 디스플레이가 때때로 멈춰 부분적인 텍스트가 표시되거나 전혀 표시되지 않는 경우가 있었습니다. st, Alacritty 및 rxvt를 포함한 다른 터미널은 문자열을 명확하게 표시했습니다.

Dickey는 성능 차이가 다양한 터미널의 스크롤 버퍼 설계로 인해 발생한다고 설명합니다. 특히 그는 rxvt 및 기타 터미널이 "일반 규칙을 따르지 않는다"고 비난합니다.

“xterm과 달리 rxvt는 모든 업데이트를 표시하려고 시도하지 않았습니다. 뒤쳐지면 따라잡기 위해 일부 업데이트를 거부합니다. 이는 내부 메모리 구성보다 겉보기 스크롤 속도에 더 큰 영향을 미쳤습니다. 한 가지 단점은 ASCII 애니메이션이 다소 부정확하다는 것입니다."

이러한 인식된 xterm 부진을 해결하기 위해 Dickey는 리소스 사용을 제안합니다. 빠른스크롤, xterm이 흐름을 따라잡기 위해 일부 화면 업데이트를 삭제할 수 있습니다. 내 테스트에서는 fastScroll이 성능을 향상시키고 xterm을 rxvt와 동등한 수준으로 가져오는 것으로 확인되었습니다. 그러나 Dickey 자신이 설명했듯이 이는 다소 어려운 버팀목입니다. "때때로 xterm(konsole과 마찬가지로)은 일부가 제거된 후 새로운 화면 업데이트 세트를 기다리면서 정지되는 것처럼 보입니다." 이런 맥락에서 다른 단말기들은 속도와 디스플레이 무결성 사이에서 가장 좋은 절충안을 찾은 것 같습니다.

자원 소비

성능 측정 기준으로 스크롤 속도를 고려하는 것이 타당한지 여부에 관계없이 이 테스트를 통해 터미널의 로드를 시뮬레이션할 수 있으며, 이를 통해 메모리나 디스크 사용량과 같은 다른 매개변수를 측정할 수 있습니다. 지정된 테스트를 실행하여 측정항목을 얻었습니다. 서열 Python 프로세스 모니터링에서. 그는 미터 데이터를 수집했습니다 getrusage() 에 ru_maxrss, 양 ru_oublock и ru_inblock 그리고 간단한 타이머.

이 테스트에서 ST는 8MB의 가장 낮은 평균 메모리 소비로 12위를 차지했는데, 이는 디자인의 주요 아이디어가 단순함이라는 점을 고려하면 놀라운 일이 아닙니다. mlterm, xterm 및 rxvt는 약 30MB를 조금 더 소비합니다. 또 다른 주목할만한 결과는 실행하는 데 40MB가 필요한 Alacritty입니다. 그런 다음 60MB에서 65MB 사이의 VTE 제품군 터미널이 있는데 이는 상당히 많습니다. 이러한 소비는 이러한 터미널이 GTK와 같은 상위 수준 라이브러리를 사용한다는 사실로 설명될 수 있습니다. Konsole은 테스트 중에 무려 XNUMXMB의 메모리를 소비하여 마지막에 올랐지만, 이는 매우 광범위한 기능으로 인해 정당화될 수 있습니다.

4년 전 얻은 이전 결과와 비교하면 모든 프로그램이 눈에 띄게 더 많은 메모리를 소비하기 시작했습니다. Xterm에는 15MB가 필요했지만 지금은 시작 시 16MB가 필요합니다. rxvt에 대한 소비도 비슷하게 증가하여 이제 기본적으로 34MB가 필요합니다. Xfce 터미널은 이전보다 20배 늘어난 32MB를 차지하지만 GNOME 터미널은 2012MB만 필요합니다. 물론 이전의 모든 테스트는 XNUMX비트 아키텍처에서 수행되었습니다. LCA XNUMX 러스티 러셀에서 이야기, 메모리 소비 증가를 설명할 수 있는 더 미묘한 이유가 많이 있다는 것입니다. 그렇긴 하지만, 우리는 이제 기가바이트의 메모리가 있는 시대에 살고 있으므로 어떻게든 관리할 것입니다.

하지만 터미널처럼 기본적인 것에 더 많은 메모리를 할당하는 것은 자원 낭비라는 생각을 지울 수 없습니다. 이러한 프로그램은 가장 작은 것 중에서 가장 작아야 하며 Linux 시스템을 장착해야 하는 지점에 도달하는 경우 어떤 "상자", 심지어 신발 상자에서도 실행할 수 있어야 합니다. ) . 그러나 이러한 숫자를 사용하면 가장 가볍고 가장 제한된 기능을 제외한 여러 터미널을 실행하는 모든 환경에서 향후 메모리 사용량이 문제가 될 것입니다. 이를 보완하기 위해 GNOME Terminal, Konsole, urxvt, Terminator 및 Xfce Terminal에는 단일 프로세스를 통해 여러 터미널을 제어하여 메모리 소비를 제한할 수 있는 데몬 모드가 있습니다.

테스트 중에 디스크 읽기-쓰기와 관련하여 또 다른 예상치 못한 결과를 얻었습니다. 여기에는 아무것도 표시되지 않을 것으로 예상했지만 일부 터미널에서는 가장 많은 양의 데이터를 디스크에 쓰는 것으로 나타났습니다. 따라서 VTE 라이브러리는 실제로 디스크에 스크롤 버퍼를 유지합니다(이 기능은 2010년에 주목받았다., 그리고 이런 일이 아직도 일어나고 있습니다). 그러나 이전 구현과 달리 이제 최소한 이 데이터는 AES256 GCM(버전 0.39.2부터). 그러나 합리적인 질문이 제기됩니다. VTE 라이브러리의 특별한 점은 구현에 대한 비표준 접근 방식이 필요하다는 것입니다.

결론

기사의 첫 번째 부분에서 우리는 VTE 기반 터미널이 좋은 기능 세트를 가지고 있다는 것을 알았지만 이제는 이로 인해 약간의 성능 비용이 발생한다는 것을 알 수 있습니다. 이제 모든 VTE 터미널은 데몬 프로세스를 통해 제어될 수 있으므로 메모리는 문제가 되지 않습니다. 그러나 RAM 및 커널 버퍼의 양에 물리적 제한이 있는 구형 시스템에는 훨씬 적은 리소스를 소비하므로 여전히 이전 버전의 터미널이 필요할 수 있습니다. VTE 터미널은 처리량(스크롤링) 테스트에서 우수한 성능을 보였지만 디스플레이 대기 시간은 GNOME 사용 설명서에 설정된 임계값보다 높습니다. VTE 개발자는 아마도 이 점을 고려해야 할 것입니다. 초보 Linux 사용자라도 터미널을 접하는 것이 불가피하다는 점을 고려하면 더욱 사용자 친화적으로 만들 수 있습니다. 숙련된 괴짜의 경우 기본 터미널에서 전환하면 눈의 피로가 줄어들고 향후 장시간 작업 세션으로 인한 업무 관련 부상 및 질병을 피할 수 있습니다. 불행하게도 오래된 xterm과 mlterm만이 10밀리초라는 마법의 핑 임계값을 제공하는데, 이는 많은 사람들이 받아들일 수 없는 수준입니다.

또한 벤치마크 측정에서는 Linux 그래픽 환경의 발전으로 인해 개발자가 여러 가지 타협을 해야 한다는 사실도 나타났습니다. 일부 사용자는 상당한 핑 감소를 제공하는 일반 창 관리자를 보고 싶어할 수 있습니다. 불행하게도 Wayland의 대기 시간을 측정하는 것은 불가능했습니다. 제가 사용한 Typometer 프로그램은 Wayland가 방지하도록 설계된 것, 즉 다른 창에 대한 감시를 위해 만들어졌습니다. Wayland 합성이 X.org보다 더 나은 성능을 발휘하기를 바라며, 미래에는 누군가가 이 환경에서 대기 시간을 측정하는 방법을 찾을 수 있기를 바랍니다.

출처 : habr.com