GNOME 46 터미널의 속도 향상폭

 (bxt.rs)
3P by GN⁺ | ★ favorite | 댓글 1개
  • GNOME 46 주기에서 VTE 기반 터미널의 입력 지연이 크게 줄어, Fedora 40 테스트에서 빠른 기준선으로 쓰인 Alacritty에 거의 근접함
  • 측정은 키 입력부터 화면 픽셀 변화까지의 종단 간 입력 지연을 하드웨어 센서로 재는 방식이라 커널·컴포지터·앱·모니터 응답 시간이 함께 반영됨
  • 단순 cat > /dev/null 입력과 복잡한 neovim 스크롤 모두에서 Console, VTE Test App, GNOME Terminal이 GNOME 45 대비 뚜렷하게 개선됨
  • 핵심 변화는 VTE가 기존 40Hz repaint timer 대신 모니터와 동기화된 프레임마다 다시 그리는 방식으로 바뀐 점일 가능성이 큼
  • VTE 0.76을 쓰는 GNOME 46 터미널은 체감 지연이 줄어들어, VTE 기반 터미널을 느리다는 이유로 피하던 사용자도 다시 시도해볼 만함

VTE 기반 터미널에서 일어난 변화

  • VTE는 여러 GNOME 터미널 에뮬레이터의 기반이 되는 Virtual TErminal library임
  • GNOME 46 주기 동안 VTE에 많은 성능 개선이 들어갔고, 사용자가 실제로 느끼는 입력 지연이 주요 확인 대상이 됨

입력 지연 측정 방식

  • 입력 지연은 키보드 키를 누른 순간부터 모니터 픽셀 색이 바뀌는 순간까지의 시간임
    • 지연이 낮을수록 앱이 더 즉각적으로 반응하는 것처럼 느껴짐
    • 낮은 지연과 높은 지연을 번갈아 비교하면 차이가 더 잘 드러남
  • 측정에는 소프트웨어 화면 캡처가 아니라 하드웨어 입력 지연 테스터를 사용함
    • 광 센서를 Teensy 보드에 연결하고, 보드는 USB로 컴퓨터에 연결됨
    • 센서는 터미널의 특정 문자 셀처럼 키 입력으로 밝기가 바뀌는 작은 화면 영역을 바라봄
    • 보드가 Space 같은 키 입력을 보내고 광량 변화를 감지한 뒤, Backspace 같은 두 번째 키로 원래 상태로 되돌림
    • 반복 사이에 임의의 대기 시간을 넣어 측정이 모니터 주사율에 고정되는 현상을 피함
  • 이 방식은 커널, 컴포지터, 애플리케이션, 모니터 응답 시간을 포함한 종단 간 지연을 측정함
    • 키보드 펌웨어 지연은 제외됨
    • 현재 보드와 펌웨어에서는 초당 약 35,500개의 광 센서 값을 기록함
  • 각 테스트는 120회 반복됨
    • 점들의 분포가 모니터의 한 번 갱신 주기 정도로 균일하게 퍼지는 것이 기대되는 형태임
    • 144Hz 모니터의 갱신 주기는 약 6.94ms이며, 예시 그래프의 점들은 7–8ms 범위에 퍼짐
    • 높은 이상치나 더 넓은 분포는 테스트 대상 앱의 지연 또는 느린 처리를 나타낼 수 있음

테스트 환경과 비교 대상

  • 테스트 시스템은 Lenovo Legion 7 Gen 7 AMD 노트북임
    • CPU는 Ryzen 7 6800H
    • GPU는 Radeon RX 6700M dGPU이며 MUX 스위치로 dGPU만 사용함
    • 모니터는 Acer Nitro XV320QU, 2560×1440, 144Hz, 100% 스케일임
    • 호스트는 Fedora 40 Silverblue Beta, Mesa 24.0.4
    • 컴포지터는 raw Mutter 46.0임
  • raw Mutter는 GNOME Shell 없이 Mutter만 실행한 단순한 테스트 환경임
    • mutter --display-server -- alacritty 같은 명령으로 실행 가능함
    • GNOME Shell 오버헤드가 거의 없는 이상적인 조건에 가까움
  • 비교 대상 터미널은 네 가지임
    • Alacritty: VTE 기반이 아니며, 이전 테스트들에서 꾸준히 빠른 터미널이라 기준선 역할을 함
    • Console: GTK 4 기반 GNOME 기본 터미널
    • VTE Test App: VTE 저장소에 있는 GTK 4 테스트 터미널
    • GNOME Terminal: GNOME 46에서는 GTK 3 앱이며, 여러 배포판에서 기본 제공됨
  • GNOME 45와 GNOME 46 비교에는 Fedora 39와 Fedora 40 toolbox 컨테이너를 사용함
    • 각 터미널은 Fedora 패키지 그대로 설치하고 추가 조정 없이 실행함
    • 창은 모니터 왼쪽 위에 배치하고, 마우스 커서는 링크 감지 로직이 결과를 왜곡하지 않도록 창 밖에 둠

단순 입력과 neovim 스크롤 결과

  • 첫 번째 테스트는 cat > /dev/null을 실행한 뒤 Space 입력으로 블록 커서가 오른쪽으로 한 칸 이동하는 시간을 측정함
    • readline 같은 추가 처리가 없는 최소 오버헤드 상황임
    • Alacritty는 Fedora 39에서 Fedora 40으로 바뀌어도 예상대로 변화가 없음
    • VTE 기반 터미널들은 GNOME 45 대비 GNOME 46에서 크게 개선되어 Alacritty와 거의 같은 수준에 도달함
    • GTK 3 기반 GNOME Terminal도 매우 근접한 결과를 보임
  • 큰 개선의 주요 원인은 Christian Hergert의 VTE 변경일 가능성이 큼
    • 기존 40Hz VTE repaint timer에서 벗어남
    • GTK 위젯답게 모니터와 동기화해 매 프레임 그리는 방식으로 바뀜
  • Console에는 몇 개의 이상치가 있었고, 프로세스 추적 때문일 가능성이 있음
    • 이 이상치는 새로 생긴 현상은 아님
    • GNOME 47에서 살펴볼 수 있는 항목으로 남음
  • 두 번째 테스트는 더 현실적인 neovim 구성을 사용함
    • neovim 설정 스냅샷에서 Ptyxis README를 열고, 광 센서가 감지할 수 있도록 일부 텍스트를 Unicode full-block 문자로 바꿈
    • Ctrl+D와 Ctrl+U를 반복해 텍스트 버퍼를 아래위로 스크롤함
    • 터미널은 밑줄, undercurl, gutter 아이콘, 상태줄 등 화면 요소를 그려야 함
  • neovim 테스트에서도 GNOME 46 터미널의 개선이 뚜렷함
    • GNOME 46의 VTE 기반 터미널들은 여전히 Alacritty와 거의 비슷한 수준임
    • Fedora 40 결과만 보면 neovim 테스트가 단순 cat 테스트보다 지연을 늘리지만, 증가 폭은 모든 터미널에서 비슷함

vtebench가 보여준 나머지 차이

  • vtebench는 입력 지연이 아니라 PTY 읽기와 파싱 성능을 측정하는 자동 벤치마크임
    • 프레임레이트나 지연 같은 중요한 요소를 다루지 않으므로 터미널 성능 전체를 이해하기에는 충분하지 않음
    • 터미널이 PTY에서 읽는 속도만 강하게 압박함
  • repaint 시간은 vtebench 결과에도 영향을 줄 수 있음
    • VTE처럼 PTY 읽기·파싱과 repaint 로직을 같은 스레드에서 실행하는 터미널에서 특히 영향이 커질 수 있음
  • GNOME 46의 VTE는 vtebench에서도 개선됨
    • 개선 폭은 입력 지연 테스트보다 더 다양함
    • 읽기와 파싱을 렌더링과 별도 스레드에서 수행하는 Alacritty 수준에는 도달하지 못함
    • 이 개선은 GNOME 46 주기 동안 VTE에 들어간 여러 최적화에서 나온 것으로 보임
  • dense_cells와 unicode 벤치마크는 기본 결과 그래프에서 제외됨
    • 두 항목은 vtebench의 주요 스트레스 테스트임
    • VTE가 여전히 크게 흔들리는 결과를 보여 그래프의 가독성을 떨어뜨림
  • 테스트 사례 기준으로 남은 차이는 거의 무시할 수 있는 수준에 가까움
    • 일부 차이는 VTE가 접근성, 스크롤바 계산, 기타 기능을 위해 추가 작업을 하는 점으로 설명될 수 있음
    • 접근성은 GNOME Terminal에서는 활성화되어 있고, GTK 4 터미널들에서는 현재 비활성화되어 있음
    • VTE 0.76을 사용하면 GNOME 46의 개선을 포함한 성능을 얻을 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 변경 덕분에 테스트한 구성의 입력 지연 중앙값이 드디어 Apple //e보다 낮아짐. Console은 약 12ms, 1983년 Apple //e는 30ms였고, 41년이 걸린 셈임
    https://www.extremetech.com/computing/261148-modern-computer...
    https://danluu.com/input-lag/
    다만 이 벤치마크는 GNOME Shell이 아니라 합성기인 raw Mutter 46.0을 썼고, raw mutter는 테스트용에 가까운 아주 기본적인 환경임. 또 키보드 지연을 포함하지 않아 종단 간 측정도 아님. 이 테스트에서는 보드가 USB로 키 입력을 보내는데, 키보드 내부 지연만 해도 60ms까지 갈 수 있음
    https://danluu.com/keyboard-latency/
    정말 중요한 기본 구성의 실제 종단 간 수치가 궁금한데, 기사에서 그걸 측정했으면 좋았을 듯함. GNOME 팀과 벤치마크 작성자의 작업은 훌륭하지만, 중요한 의문은 남아 있음. Apple //e는 하드웨어 가속을 썼고 Unicode도 처리하지 않았으니 차이는 많지만, 그래도 41년 넘은 기계의 인간적인 반응성으로 돌아갈 수 있으면 좋겠음

    • 오히려 작성자가 키보드 지연을 제외한 건 잘한 일이라고 봄. 사람마다 서로 다른 키보드, USB 인터페이스, 컴퓨터, 운영체제 버전을 쓰고, 허브나 KVM까지 끼어들 수 있음
      그런 구성 요소의 지연이 테스트 중 크게 흔들리면, 이 글의 핵심인 VTE 지연 개선을 분석하기 어려워짐. 설령 완전히 일정하더라도 절대값에 상수처럼 더해질 뿐이라 결론은 바뀌지 않음. 그래서 지연 차이를 백분율로 표현하면 안 됨. 표본 집합에서는 정규화할 수 있는 상수가 있지만, 전체 사용자 집단에는 정규화할 수 없는 상수가 많기 때문임. Mutter 부분은 흥미로운데, GNOME이 Mutter 위에 올라가므로 절대적인 지연 개선은 비슷하게 나타날 가능성이 있어 보임. 다만 GNOME도 키보드 지연처럼 원치 않는 변동을 만들 수 있어 실제 확인해 보고 싶음
    • 그러면 Apple 2e를 쓰고 현대 운영체제의 편의 기능은 포기하면 됨. 무료로 제공하려고 애쓰는 오픈소스 개발자들을 길게 깎아내리는 식이라 받아들이기 어렵다
    • 링크된 키보드 지연 글의 방법론에서 키가 물리적으로 이동하는 시간까지 포함한 점은 늘 조금 거슬렸음
    • Unicode 처리는 사람들이 믿는 것만큼 어려운 문제가 아님. 이상해지는 경계 사례는 있지만 많지 않고 해결도 쉬움
      이 글에서 정말 거슬린 건 최신 테스트 버전 이전의 Gnome에서 다시 그리기 속도가 고정 40Hz였다는 점임. 대체 누가 그렇게 결정한 건가
    • 키보드 지연 글의 60ms 주장은 의심스러움. 키 입력에서 USB까지 지연이 키보드에서 흔히 60ms라면 리듬 게임은 말 그대로 플레이 불가능했을 것임. 그런데 지금까지 쓴 어떤 키보드에서도 그런 문제를 겪지 않았음

  • 좋음. VTE 개발자들이 성능에 집중한 점도 좋고, 글의 하드웨어 기반 측정 과정도 인상적임
    지연 측정에 광센서를 쓴 방식은 Ben Heck의 노골적인 이름의 “Xbox One Controller Monitor” [1] 제품을 떠올리게 함. 게임 콘솔 컨트롤러 버튼 상태를 직접 읽고 광센서와 결합해 게임 개발자가 지연을 낮게 유지하도록 돕는 제품임. 멋져 보이지만 가격은 900달러임
    [1]: https://www.benheck.com/xbox1monitor/

    • 성능에 집중하기 시작한 건 최근 일임. VTE는 원래 꽤 느렸음
    • 재미있는 사실: 수직 동기화가 켜져 있으면 지연은 센서를 어디에 두느냐에 따라 달라짐

  • 이 글과 링크된 글 모두 광센서를 모니터 중간쯤에 둠. 측정값 비교에는 문제없지만, 일반적인 모니터 상당수에서는 60Hz 기준으로 센서를 화면 위쪽에 두면 약 8ms 더 빠르게, 아래쪽에 두면 약 8ms 더 느리게 측정됨. 픽셀이나 라인이 위에서 아래로 구동되기 때문이고, 기본적으로 CRT와 비슷함
    그러니 세부로 들어간다면, 광센서 신호에서 픽셀이 켜졌다고 판단할 임계값을 어디에 둘지처럼 이 점도 언급해야 함. 글의 수치를 보면 8ms는 꽤 큰 차이임. 마찬가지로 “모니터 X가 모니터 Y보다 30ms 느리다”라고만 말하는 것도 과장일 수 있음. 내 구성과 설정 X, Y, Z에서 이렇게 측정됐다고 봐야 함. 모니터가 지연만 추가하고 체감 효과는 없는 이상한 향상 기능을 적용하는지, 모니터를 바꿀 때 그래픽 카드나 드라이버가 친절한 척하며 보정, 스케일링, 향상 프로필로 몰래 바꾸지 않았는지도 확인해야 함. 이런 장치들은 보통 아무 경고도 하지 않는데, 실제로 본 사례가 몇 가지 있음

    • 화면이 실시간으로 스크롤되는 걸 본다면, 나는 화면의 아래쪽 1/3을 볼 가능성이 훨씬 큼

  • 소비자용 하드웨어에서 불가능해 보였던 초현실적인 3D 장면과 게임을 렌더링하는 세상에 살면서도, 동시에 터미널에 텍스트를 찍는 일을 아직 완벽하게 만들려고 애쓰는 세상이라는 게 웃김

    • 일부는 그래픽에 더 최적화하면서 생긴 일 아닌가 싶음. 둘 사이에는 절충이 있고, 그래픽이 좋아질수록 텍스트는 나빠지는 경향이 있을 수 있음. 터미널이 GPU 가속을 쓰며 일부 상쇄되지만, 그래도 그 그래픽 파이프라인 비용을 치르게 됨
    • 예전에는 별로 중요하지 않았던 것도 있지 않을까. “작동은 한다” 정도였고, 최근까지는 많은 터미널 사용 사례에서 해결해야 할 네트워크 지연이 컸음

  • 속도와는 관련 없지만, Linux에 Mac OSX Terminal처럼 종료했다가 다시 열면 모든 탭, 각 탭의 명령 기록과 스크롤백을 되살려 주는 터미널이 있는지 궁금함. Mac 쪽은 탭마다 다른 bash 기록 파일을 설정하는 식으로 처리함
    이 용도에는 GUI 터미널을 선호함

    • 조금 다른 이야기지만, 방금 1시간 전에 Mac의 iterm2가 tmux와 통합될 수 있다는 걸 알게 됨. tmux를 -CC 인자로 실행하면 tmux 세션이 iterm2의 GUI 창과 탭에 매핑되고, ssh로 원격 머신의 tmux를 써도 가능함
      tmux 제어 단축키와 명령을 항상 까먹었는데, 이 기능이 꽤 기대됨
      [1] https://iterm2.com/documentation-tmux-integration.html
    • 탭을 모두 닫은 뒤 새 탭을 열면 어떻게 되는지 궁금함. 탭별 기록이 닫을 때 일반 기록 파일로 다시 합쳐져서 새 탭에서도 그 명령들을 쓸 수 있게 되는 걸까
    • 나는 Tmux를 씀. 터미널에 구애받지 않는 멀티플렉서라 지속성과 자동화 능력이 강력해짐
      https://github.com/tmux/tmux/wiki
    • GUI 터미널을 선호한다면 마음에 안 들 수 있지만, 누군가에게는 유용할 수 있음: https://github.com/tmux-plugins/tmux-resurrect
      물론 tmux는 원하는 어떤 GUI 터미널 에뮬레이터와도 함께 쓸 수 있음
    • 딱 같은 걸 찾고 있었음. 지금은 재부팅 사이 상태 유지를 위해 tmux와 tmux-ressurect를 쓰는데, 그럭저럭 동작하지만 좋은 해킹일 뿐 여전히 해킹처럼 느껴짐
      warp를 빼면 이 문제에 대한 진짜 해결책이 거의 없다는 게 아쉬움. 내 작은 UX 꿈은 이런 작업 공간 저장 기능이 운영체제 전체와 그 안의 앱들에 통합되는 것임. 그러면 멋질 듯함

  • 몇 년 동안 Gnome을 쓰다가 2년 전 sway와 alacritty로 바꿨는데, 솔직히 차이를 전혀 모르겠음. 고급 오디오 장비처럼 내 귀와 눈이 그 차이를 구분하도록 조율되지 않은 것 같음

    • 다시 돌아가 본 적 있음? 지연이 줄어들 때보다 늘어날 때 더 잘 느껴지는 경우가 많음
    • 몇 년 동안 Gnome을 써 왔고 지금은 Gnome 46인데, Gnome 45와 비교해 터미널 지연 차이를 느끼지 못했음. 나도 이런 걸 잘 못 느끼는 편인 듯함
    • 공정한 비교는 아닐 수 있지만, 약 20년 전 커널을 컴파일하는 동안 gnome-terminal이 CPU 절반을 써서 그 뒤로 쓰지 않기로 했음. Xterm은 약 2%를 썼음
    • 지연이나 반응성에서 내가 신경 쓰는 건 vim에서 스크롤할 때 터미널 때문에 토할 것 같아지는지뿐임
    • 화면이나 키보드가 이미 충분한 지연을 더하고 있어서 어떤 소프트웨어를 써도 좋은 결과가 안 나올 수도 있음. 나쁜 지연과 아주 나쁜 지연의 차이는 그렇게 뚜렷하지 않음. 게임용 하드웨어를 써 봤는지 궁금함

  • 드디어 거대한 파일을 cat하는 것만이 아닌 터미널 벤치마크가 나옴. 더 다양한 터미널, 특히 Linux 기본 콘솔까지 같은 테스트로 보고 싶음

  • 주제에서 벗어나지만, Gnome Terminal에서 가장 싫은 점은 기본으로 작은 창을 연다는 것임. 내 화면의 1/4 정도 크기이고, 크기를 바꿔도 재시작 후 기억하지 않음. 결국 설정에 들어가 열과 행 수를 직접 지정해야 함

    • 그런 동작은 많은 터미널에서 꽤 흔함. 바로 떠오르는 것만 해도 기본 macOS Terminal과 Windows Terminal 모두 설정에서 기본 크기를 바꿔야 하는 식임
      개인적으로는 기본 크기를 두고, 더 큰 공간이 필요한 특정 창만 리사이즈하는 방식을 선호함. 그래도 리사이즈를 기억하는 옵션은 최소한 있어야 함
    • 설정에서 바꿀 수 있음
      햄버거 메뉴 > Preferences > 프로필 이름으로 들어가면 됨. 내 프로필은 그냥 “Unnamed”임. “initial terminal size”를 바꾸면 원하는 대로 됨. 나는 132x43으로 설정해 둠
    • 크기가 제각각인 터미널을 여러 개 열어 두는 일이 많음. 어떤 크기를 기억하는 게 맞는지 명확하지 않음
      그래서 그런 시도를 하지 않았으면 함. 소프트웨어가 내가 원하는 걸 확신할 수 있을 때 똑똑하게 굴면 괜찮지만, 그렇지 않으면 또 하나의 “제가 자동으로 망쳐드렸습니다. 감사하죠?” 사례가 됨
    • 더 새로운 gnome 터미널인 Console은 창 크기를 기억함
    • 기억하기로는 이건 CMD.EXE에서 온 기능이었음

  • 공개되면 Mitchell Hashimoto의 Ghostty 터미널도 벤치마크에 포함되면 좋겠음. 아직은 개발과 다듬기 단계이고 비공개 베타임
    https://mitchellh.com/ghostty

  • debian에서 xterm과 i3wn을 쓰는데 이보다 빠른 걸 경험한 적이 없음. 터미널에 GPU를 낭비한다는 생각은 해 본 적도 없어서, alacritty는 개인적으로 과하다고 봄

    • 나도 비슷하게 느낌. xterm을 쓸 때 지연을 생각해 본 적이 없음. 번역 기능이나 sixel 같은 무거운 기능도 매일 쓰는데도 그렇다. 사람들이 Athena 위젯 스타일 때문에 무시하는 것 같은데, 실제로는 훌륭함
답변달기