Xterm.js: 버퍼 성능 향상

혼합될 수 있는 또 다른 접근 방식: indexeddb, websql 또는 파일 시스템 API를 사용하여 비활성 스크롤백 항목을 디스크로 페이지 아웃합니다 🤔

훌륭한 제안입니다. 3. 트루 컬러도 지원하면서 메모리를 절약할 수 있으므로 현재로서는 가장 좋은 방법이라는 점에 동의합니다.

거기에 도달하고 상황이 계속해서 잘 진행된다면 5. 에서 제안한 대로 최적화하거나 그 당시 마음에 떠오르는 다른 방식으로 최적화할 수 있습니다.

3. 멋져요👍.

@mofux , 디스크 저장소 지원 기술을 사용하여 메모리 공간을 줄이는 사용 사례가 분명히 있지만, 이는 사용자에게 디스크 저장소 사용 권한을 요청하는 브라우저 환경에서 라이브러리의 사용자 경험을 저하시킬 수 있습니다.

미래 지원에 관하여:
생각하면 할수록 tty 데이터를 구문 분석하고, 라인 버퍼를 유지하고, 링크를 연결하고, 검색 토큰을 일치시키는 등의 힘든 작업을 모두 수행하는 WebWorker 있다는 생각이 더 많이 듭니다. 기본적으로 UI를 차단하지 않고 별도의 백그라운드 스레드에서 무거운 작업을 수행합니다. 하지만 이것은 아마도 4.0 릴리스에 대한 별도의 논의의 일부여야 한다고 생각합니다 😉

앞으로 WebWorker에 대해 +100이지만 모든 브라우저에서 사용할 수 있는 것은 아니기 때문에 지원하는 브라우저의 변경 목록 버전이 필요하다고 생각합니다...

Int32Array 라고 말하면 환경에서 지원하지 않는 경우 일반 배열이 됩니다.

@mofux 앞으로 WebWorker 와 좋은 생각 👍

@AndrienkoAleksandr 예, WebWorker 를 사용하려면 기능 감지를 통해 대안도 지원해야 합니다.

와우 리스트 좋네요 :)

나는 또한 일반적인 터미널 사용의 90% 이상에 대해 메모리 소비를 크게 줄일 것을 약속하기 때문에 3 에 기대는 경향이 있습니다. 이 단계에서 Imho 메모리 최적화가 주요 목표가 되어야 합니다. 이 외에도 특정 사용 사례에 대한 추가 최적화가 적용될 수 있습니다(내 생각: ncurses와 같은 "캔버스와 같은 앱"은 수많은 단일 셀 업데이트를 사용하고 시간이 지남에 따라 [start, end] 목록을 다소 저하시킬 것입니다) .

@AndrienkoAleksandr 네, 웹 작업자 아이디어도 메인 스레드에서 _일부_ 부담을 덜어줄 수 있기 때문에 좋아합니다. 여기서 문제는 (원하는 모든 대상 시스템에서 지원되지 않을 수 있다는 사실 외에도) _some_입니다. JS 부분은 모든 최적화에서 더 이상 그렇게 큰 문제가 아닙니다. xterm.js는 시간이 지남에 따라 보아왔습니다. 실제 문제는 성능 측면에서 브라우저의 레이아웃/렌더링입니다...

@mofux 일부 "외부 메모리"에 대한 페이징은 좋은 생각이지만 xterm.js가 있는 "대화형 터미널 위젯"이 아니라 더 높은 추상화의 일부여야 합니다. 이것은 imho 애드온으로 달성할 수 있습니다.

주제 외: 배열 대 typedarrays 대 asm.js로 몇 가지 테스트를 했습니다. 내가 말할 수있는 것은 - OMG, 간단한 변수로드 및 세트의 경우 1 : 1,5 : 10 와 같습니다 (FF에서는 훨씬 더). 순수한 JS 속도가 정말 아프기 시작하면 "asm 사용"이 도움이 될 수 있습니다. 그러나 근본적인 변화를 의미하기 때문에 이것을 최후의 수단으로 생각합니다. 그리고 웹 어셈블리는 아직 배송할 준비가 되지 않았습니다.

주제 외: 배열 대 typedarrays 대 asm.js로 몇 가지 테스트를 했습니다. 내가 말할 수있는 것은 - OMG, 간단한 가변로드 및 세트의 경우 1 : 1,5 : 10과 같습니다 (FF에서는 훨씬 더)

@jerch 는 배열 대 typedarrays가 1:1에서 1:5

쉼표로 좋은 캐치 - 나는 10:15:100 속도 현명함을 의미했습니다. 그러나 FF 유형 배열에서만 일반 배열보다 약간 빠릅니다. asm은 FF, 웹킷(Safari), 깜박임/V8(Chrome, Opera)로 테스트된 모든 브라우저에서 js 어레이보다 10배 이상 빠릅니다.

@jerch cool, 더 나은 메모리와 함께 typedarrays의 50% 속도 향상은 지금으로서는 확실히 투자할 가치가 있습니다.

메모리 절약에 대한 아이디어 - 모든 문자에 대해 width 를 제거할 수 있습니다. 더 저렴한 wcwidth 버전을 구현하려고 합니다.

@jerch 우리는 그것에 꽤 많이 접근해야 하고 그것을 지연 로드하거나 어떤 것도 할 수 없습니다. 왜냐하면 리플로우가 올 때 버퍼에 있는 모든 문자의 너비가 필요하기 때문입니다. 그것이 빠르더라도 우리는 여전히 그것을 유지하기를 원할 것입니다.

지정되지 않은 경우 1로 가정하고 선택 사항으로 만드는 것이 더 나을 수 있습니다.

type CharData = [string, number?]; // not sure if this is valid syntax

[
  // 'a'
  ['a'],
  // '文'
  ['文', 2],
  // after wide
  ['', 0],
  ...
]

@Tyriar 예 - 이미 작성
속도 향상은 조회 테이블에 대해 16k 바이트의 비용으로 내 컴퓨터에서 10~15배입니다. 여전히 필요한 경우 둘의 조합이 가능할 수도 있습니다.

앞으로 더 많은 플래그를 지원할 예정입니다: https://github.com/sourcelair/xterm.js/issues/580

또 다른 생각: 터미널의 맨 아래 부분( Terminal.ybase ~ Terminal.ybase + Terminal.rows )만 동적입니다. 데이터의 대부분을 구성하는 스크롤백은 완전히 정적입니다. 아마도 이것을 활용할 수 있을 것입니다. 최근까지 이것을 몰랐지만 행 삭제(DL, CSI Ps M)와 같은 것조차도 스크롤백을 다시 아래로 가져오지 않고 오히려 다른 행을 삽입합니다. 마찬가지로 위로 스크롤(SU, CSI Ps S)하면 Terminal.scrollTop 의 항목이 삭제되고 Terminal.scrollBottom 항목이 삽입됩니다.

터미널의 하단 동적 부분을 독립적으로 관리하고 줄이 밀려 나올 때 뒤로 스크롤하면 상당한 이득을 얻을 수 있습니다. 예를 들어, 하단 부분은 속성 수정, 더 빠른 액세스 등을 선호하기 위해 더 장황할 수 있는 반면 스크롤백은 위에서 제안한 아카이브 형식에 더 가깝습니다.

또 다른 생각: CharAttributeEntry 를 행으로 제한하는 것이 대부분의 응용 프로그램이 작동하는 방식이므로 더 나은 아이디어일 수 있습니다. 또한 터미널 크기가 조정되면 동일한 스타일을 공유하지 않는 "빈" 패딩이 오른쪽에 추가됩니다.

예:

빨간색/녹색 diff의 오른쪽에는 스타일이 지정되지 않은 "빈" 셀이 있습니다.

@티리아르
이 문제를 의제로 되돌릴 기회가 있습니까? 적어도 출력 집약적인 프로그램의 경우 터미널 데이터를 유지하는 다른 방법은 많은 메모리와 시간을 절약할 수 있습니다. 2/3/4의 일부 하이브리드는 입력 문자열의 단일 문자를 분할하고 저장하는 것을 방지할 수 있다면 엄청난 처리량 향상을 제공합니다. 또한 속성이 변경된 후에만 저장하면 메모리를 절약하는 데 도움이 됩니다.

예시:
새로운 파서를 사용하면 속성을 어지럽히지 않고 입력 문자를 저장할 수 있습니다. 왜냐하면 해당 문자열의 중간에 변경되지 않는다는 것을 알고 있기 때문입니다. 해당 문자열의 속성은 wcwidth(예, 줄 바꿈을 찾으려면 여전히 필요함) 및 줄 바꿈 및 중지와 함께 다른 데이터 구조 또는 속성에 저장할 수 있습니다. 이것은 기본적으로 데이터가 수신될 때 셀 모델을 포기합니다.
문제는 터미널 데이터의 드릴다운 표현(예: 렌더러 또는 일부 이스케이프 시퀀스/사용자가 커서를 이동하려는 경우)이 시작되어 발생합니다. 그런 일이 발생하면 여전히 셀 계산을 수행해야 하지만 터미널 cols 및 rows 내의 내용에 대해서만 이 작업을 수행하는 것으로 충분해야 합니다. (스크롤된 콘텐츠에 대해서는 아직 확실하지 않으므로 더 캐시에 저장할 수 있고 다시 그리는 비용이 저렴할 수 있습니다.)

@jerch 2주 후에 언젠가 프라하에서 @mofux를 만날 예정이며 이를 다루는 텍스트 속성이 처리되는 방식에 대한 내부 개선 작업을 시작/시작할 예정입니다 😃

https://github.com/xtermjs/xterm.js/pull/1460#issuecomment -390500944에서

모든 문자가 두 번 평가되어야 하기 때문에 알고리즘은 다소 비쌉니다.

@jerch 버퍼에서 더 빠른 텍스트 액세스에 대한 아이디어가 있으면 알려주십시오. 현재 대부분은 알다시피 단일 문자이지만 ArrayBuffer , 문자열 등이 될 수 있습니다. 저는 우리가 어떻게든 변경할 수 없는 스크롤백의 이점을 더 활용하는 것에 대해 생각해야 한다고 생각했습니다.

글쎄, 나는 과거에 ArrayBuffers로 많은 것을 실험했습니다.

• 일반적인 방법의 런타임과 관련하여 Array 보다 약간 나쁩니다(엔진 공급업체에 의해 최적화되지 않을 수 있음)
• new UintXXArray 는 [] 사용한 리터럴 배열 생성보다 훨씬 나쁩니다.
• 데이터 구조를 미리 할당하고 재사용할 수 있으면(최대 10배) 여러 번 보상합니다. 여기에서 혼합 배열의 연결 목록 특성이 배후에서 과도한 할당 및 gc로 인해 성능을 저하시킵니다.
• 문자열 데이터의 경우 앞뒤 변환은 모든 이점을 먹습니다 - 유감스럽게도 JS는 Uint16Array 변환기에 기본 문자열을 제공하지 않습니다( TextEncoder 부분적으로 가능).

ArrayBuffer 에 대한 내 발견은 변환 패널티로 인해 문자열 데이터에 사용하지 않는 것이 좋습니다. 이론적으로 터미널은 node-pty에서 터미널 데이터까지 ArrayBuffer 를 사용할 수 있습니다(이는 프론트엔드로 가는 도중에 여러 변환을 저장할 수 있음). 렌더링이 그런 식으로 수행될 수 있는지 확실하지 않은 경우 항상 최종 uint16_t 에서 string 로의 변환이 필요합니다. 그러나 마지막 문자열 생성은 저장된 런타임의 대부분을 먹어치우고 터미널을 내부적으로 추악한 C-ish 짐승으로 만들 것입니다. 따라서 나는 이 접근 방식을 포기했습니다.

TL;DR ArrayBuffer 는 데이터 구조를 미리 할당하고 재사용할 수 있다면 더 좋습니다. 다른 모든 경우에는 일반 배열이 더 좋습니다. 문자열은 ArrayBuffers에 압축할 가치가 없습니다.

내가 생각해 낸 새로운 아이디어는 가능한 한 문자열 생성을 줄이려는 시도입니다. 불쾌한 분할 및 조인을 피하려고 합니다. 새로운 InputHandler.print 메소드, wcwidth 및 line stop을 염두에 두고 위의 두 번째 아이디어를 기반으로 합니다.

• print 이제 여러 터미널 라인까지 전체 문자열을 가져옵니다.
• 현재 속성과 함께 해당 문자열을 변경 없이 간단한 포인터 목록에 저장합니다(문자열 alloc 또는 gc 없음, 사전 할당된 구조와 함께 사용되는 경우 목록 할당을 피할 수 있음).
• wcwidth(string) % cols 만큼 커서 이동
• 특별한 경우 \n (하드 줄 바꿈): 커서를 한 줄 앞으로 이동, 포인터 목록의 위치를 ​​하드 줄 바꿈으로 표시
• wrapAround를 사용한 특별한 경우 줄 오버플로: 문자열의 위치를 ​​소프트 줄 바꿈으로 표시
• 특별한 경우 \r : 마지막 줄 내용(현재 커서 위치에서 마지막 줄 바꿈까지)을 일부 줄 버퍼에 로드하여 덮어씁니다.
• \r 케이스에도 불구하고 위와 같이 데이터가 흐릅니다. 셀 추상화나 문자열 분할이 필요하지 않습니다.
• 아무도 실제 cols x rows 표현을 요청하지 않는 한 속성 변경은 문제가 되지 않습니다(전체 문자열과 함께 저장되는 attr 플래그만 변경함).

Btw wcwidths는 자소 알고리즘의 하위 집합이므로 미래에 서로 바꿔 사용할 수 있습니다.

이제 위험한 부분 1 - 누군가 cols x rows 내에서 커서를 이동하려고 합니다.

• cols 줄바꿈에서 뒤로 이동 - 현재 터미널 내용의 시작
• 모든 줄 바꿈은 실제 터미널 줄을 나타냅니다.
• 한 페이지의 셀 모델에 로드
• 까다로운 작업을 수행하십시오. 속성 변경이 요청되면 운이 좋지 않아 전체 셀 모델 또는 문자열 분할 및 삽입 모델로 폴백해야 합니다(후자는 성능이 저하될 수 있음).
• 데이터가 다시 흐릅니다. 이제 해당 페이지의 버퍼에 저하된 문자열 및 속성 데이터가 있습니다.

이제 위험한 부분 2 - 렌더러가 무언가를 그리기를 원합니다.

• 셀 모델로 드릴다운해야 하거나 줄 바꿈 및 텍스트 속성이 있는 문자열 오프셋을 제공할 수 있는지 여부는 렌더러에 따라 다릅니다.

장점:

• 매우 빠른 데이터 흐름
• 가장 일반적인 InputHandler 방법에 최적화됨 - print
• 터미널 크기 조정 시 리플로우 라인을 가능하게 합니다.

단점:

• 거의 모든 다른 InputHandler 방법은 이 흐름 모델을 중단하고 중간 셀 추상화가 필요하다는 의미에서 위험합니다.
• 렌더러 통합이 불분명합니다 (적어도 atm에게)
• 앱과 같은 저주의 성능이 저하될 수 있습니다(일반적으로 더 "위험한" 시퀀스가 ​​포함됨).

글쎄, 이것은 많은 세부 사항이 아직 다루어지지 않았기 때문에 사용 가능한 atm과는 거리가 먼 아이디어의 대략적인 초안입니다. 특히 "위험한" 부분은 많은 성능 문제로 인해 불쾌해질 수 있습니다(예: 더 나쁜 gc 동작 등으로 버퍼 성능 저하).

@jerch

문자열은 ArrayBuffers에 압축할 가치가 없습니다.

Monaco는 ArrayBuffer s에 버퍼를 저장하고 꽤 고성능이라고 생각합니다. 아직 구현에 대해 자세히 살펴보지는 않았습니다.

특히 불쾌한 분할 및 조인을 피하려고 합니다.

어느 것?

저는 스크롤백이 어떻게든 불변이라는 이점을 더 많이 활용하는 것에 대해 생각해야 한다고 생각했습니다.

한 가지 아이디어는 뷰포트 섹션에서 스크롤백을 분리하는 것이었습니다. 줄이 스크롤백으로 이동하면 스크롤백 데이터 구조로 푸시됩니다. 2개의 CircularList 개체를 상상할 수 있습니다. 하나는 라인이 절대 변경되지 않도록 최적화되고 다른 하나는 그 반대입니다.

@Tyriar 스크롤

@티리아르
변환을 하나로 제한할 수 있다면 ArrayBuffer에 문자열을 저장하는 것이 합리적입니다. 그것은 모든 곳에서 문자열을 처리하는 것보다 약간 낫습니다. 이것은 node-pty가 원시 데이터도 제공할 수 있기 때문에 가능합니다(또한 websocket도 원시 데이터를 제공할 수 있음).

특히 불쾌한 분할 및 조인을 피하려고 합니다.

어느 것?

전체 접근 방식은 _minimize_ 분할 을 전혀 피하는 것 입니다. 아무도 버퍼링된 데이터로 커서 점프를 요청하지 않으면 문자열이 분할되지 않고 렌더러로 바로 이동할 수 있습니다(지원되는 경우). 셀 분할 및 나중에 조인이 전혀 없습니다.

@jerch 글쎄, 뷰포트가 확장되면 할 수 있습니다. 줄을 삭제할 때 스크롤백을 가져올 수도 있다고 생각합니다. 그것이 올바른 행동인지 100% 확신할 수는 없습니다.

@Tyriar 아 맞다. 후자도 확실하지 않지만 기본 xterm은 실제 마우스 또는 스크롤 막대 스크롤에만 이를 허용한다고 생각합니다. SD/SU조차도 스크롤 버퍼 콘텐츠를 "활성" 터미널 뷰포트로 다시 이동하지 않습니다.

ArrayBuffer가 사용되는 monaco 편집기의 소스를 알려 주시겠습니까? 내가 직접 찾을 수 없는 것 같습니다 : 홍당무:

흠 그냥 TextEncoder/Decoder 사양을 다시 읽고 node-pty에서 프론트엔드까지 ArrayBuffers를 사용하여 어느 시점에서 어려운 방식으로 번역하지 않는 한 기본적으로 utf-8에 고정되어 있습니다. xterm.js utf-8을 인식하게 만드시겠습니까? Idk, 이것은 더 높은 유니코드 문자에 대한 많은 중간 코드 포인트 계산을 포함합니다. Proside - ASCII 문자에 대한 메모리를 절약합니다.

@rebornix monaco가 버퍼를 저장하는 위치에 대한 포인터를 줄 수 있습니까?

다음은 유형이 지정된 배열과 새 파서에 대한 몇 가지 숫자입니다(채택하기 더 쉬움).

• UTF-8(Uint8Array): print 작업이 190MB/s에서 290MB/s로 점프합니다.
• UTF-16(Uint16Array): print 작업이 190MB/s에서 320MB/s로 점프합니다.

전반적으로 UTF-16이 훨씬 더 나은 성능을 보이지만 파서가 이에 최적화되어 있기 때문에 예상했던 것입니다. UTF-8은 중간 코드 포인트 계산에 어려움을 겪습니다.

문자열에서 형식화된 배열로의 변환은 내 벤치마크 ls -lR /usr/lib 의 JS 런타임을 ~4% 소모합니다( InputHandler.parse 루프를 통해 수행되는 항상 100ms 미만). 나는 역변환을 테스트하지 않았다(이것은 암묵적으로 atm in InputHandller.print 에서 셀 수준으로 수행됨). 전체 런타임은 문자열보다 약간 나쁩니다(파서에 저장된 시간은 변환 시간을 보상하지 않습니다). 다른 부분도 배열을 인식하는 형식인 경우 변경될 수 있습니다.

그리고 해당 스크린샷( ls -lR /usr/lib 테스트):

문자열로:

Uint16Array 사용:

EscapeSequenceParser.parse 차이점에 유의하십시오. 이는 형식화된 배열에서 이익을 얻을 수 있습니다(~30% 더 빠름). InputHandler.parse 는 변환을 수행하므로 형식화된 배열 버전에서는 더 나쁩니다. 또한 GC Minor는 형식화된 배열에 대해 더 많은 작업을 수행합니다(배열을 버리기 때문에).

편집: 스크린샷에서 또 다른 측면을 볼 수 있습니다. GC는 ~20% 런타임과 관련되고 장기 실행 프레임(빨간색 플래그)은 모두 GC와 관련됩니다.

또 다른 다소 급진적인 아이디어:

1. 자체 arraybuffer 기반 가상 메모리 생성, 큰 것(>5MB)
   어레이 버퍼의 길이가 int8 에서 int16 에서 int32 로 4개의 투명 스위치의 배수인 경우 유형이 가능합니다. 할당자는 Uint8Array 에서 사용 가능한 인덱스를 반환합니다. 이 포인터는 간단한 비트 이동에 의해 Uint16Array 또는 Uint32Array 위치로 변환될 수 있습니다.
2. 들어오는 문자열을 UTF-16의 경우 uint16_t 유형으로 메모리에 씁니다.
3. 파서는 문자열 포인터에서 실행되고 문자열 조각 대신 이 메모리에 대한 포인터를 사용하여 InputHandler 메서드를 호출합니다.
4. 가상 메모리 내부에 터미널 데이터 버퍼를 네이티브 JS 객체 대신 구조체와 같은 유형의 링 버퍼 배열로 생성합니다. 아마도 다음과 같을 것입니다(여전히 셀 기반).

struct Cell {
    uint32_t *char_start;  // start pointer of cell content (JS with pointers hurray!)
    uint8_t length;        // length of content (8 bit here is sufficient)
    uint32_t attr;         // text attributes (might grow to hold true color someday)
    uint8_t width;         // wcwidth (maybe merge with other member, always < 4)
    .....                  // some other cell based stuff
}

장점:

• 가능한 경우 JS 개체와 GC를 생략합니다(몇 개의 로컬 개체만 남음).
• 필요한 가상 메모리에 대한 단 하나의 초기 데이터 복사
• malloc 및 free 비용이 거의 없음(할당자/할당자의 영리함에 따라 다름)
• 많은 메모리를 절약할 수 있습니다(JS 개체 메모리 오버헤드 방지).

단점:

• Cavascript Horror Show에 오신 것을 환영합니다 :scream:
• 구현하기 어렵고 모든 것이 변경됨
• 속도 이점은 실제로 구현될 때까지 불분명합니다.

:웃다:

구현하기 어려운 재미, 모든 것이 변경됩니다 😉

이것은 Monaco가 작동하는 방식에 더 가깝습니다. 캐릭터 메타데이터를 저장하기 위한 전략을 논의하는 이 블로그 게시물을 기억했습니다. https://code.visualstudio.com/blogs/2017/02/08/syntax-highlighting-optimizations

네 기본적으로 같은 생각입니다.

monaco가 버퍼를 저장하는 위치에 대한 내 대답이 너무 늦지 않기를 바랍니다.

Alex와 저는 Array Buffer를 선호하며 대부분의 경우 우수한 성능을 제공합니다. ArrayBuffer를 사용하는 일부 장소:

• 텍스트 버퍼의 줄 바꿈 오프셋 https://github.com/Microsoft/vscode/blob/rebornix/review/src/vs/editor/common/model/pieceTreeTextBuffer/pieceTreeBase.ts#L31 .
• 오프셋 <--> 위치 매핑 https://github.com/Microsoft/vscode/blob/rebornix/review/src/vs/editor/common/viewModel/prefixSumComputer.ts#L26
• 토큰 https://github.com/Microsoft/vscode/blob/rebornix/review/src/vs/editor/common/model/textModelTokens.ts#L1 이 토큰에 관심이 있을 수 있습니다. 소스 코드를 다른 스레드에서 토큰화하여 Array Buffer에 저장한 다음 View Model의 백업 저장소와 동일한 Array 버퍼를 사용합니다. 웹 워커에서 토크나이저(node-oniguruma)와 통신하는 방법도 생각 중인데 UI 코드는 응답성에 대해 걱정할 필요가 없으며 토큰은 SharedArrayBuffer에 의해 메인 스레드와 공유될 수 있습니다.

V8 문자열은 조작하기 쉽기 때문에 배열 버퍼 대신 텍스트 버퍼에 간단한 문자열을 사용합니다.

• 파일 로딩 초기에 인코딩/디코딩을 하기 때문에 파일은 JS 스트링으로 변환됩니다. V8은 문자를 저장하기 위해 1바이트 또는 2바이트를 사용할지 여부를 결정합니다.
• 우리는 텍스트 버퍼를 매우 자주 편집합니다. 문자열은 다루기 쉽습니다.
• nodejs 네이티브 모듈을 사용하고 있으며 필요한 경우 V8 내부에 액세스할 수 있습니다.

커밋이 추가될 때 깨지지 않도록 @rebornix 의 링크를 고정

• https://github.com/Microsoft/vscode/blob/f1dcaaea48263a882017521f20c91149a516eca1/src/vs/editor/common/model/pieceTreeTextBuffer/pieceTreeBase.ts#L31
• https://github.com/Microsoft/vscode/blob/f1dcaaea48263a882017521f20c91149a516eca1/src/vs/editor/common/viewModel/prefixSumComputer.ts#L26
• https://github.com/Microsoft/vscode/blob/f1dcaaea48263a882017521f20c91149a516eca1/src/vs/editor/common/model/textModelTokens.ts#L1

다음 목록은 메모리 사용량 및/또는 런타임을 줄이는 데 도움이 될 수 있는 흥미로운 개념을 간략하게 요약한 것입니다.

• FlatJS(https://github.com/lars-t-hansen/flatjs) - arraybuffer 기반 힙으로 코딩하는 데 도움이 되는 메타 언어
• http://2ality.com/2017/01/shared-array-buffer.html (ES2017의 일부로 발표됨, 실제 동시성과 실제 원자성을 갖춘 매우 유망한 아이디어 외에 Spectre로 인해 미래가 불확실할 수 있음)
• webassembly/asm.js (현재 상태? 아직 사용 가능? 얼마 동안 개발을 따르지 않았으며 몇 년 전 게임 AI용 C lib와 함께 emscripten을 asm.js에 사용했지만 인상적인 결과를 얻었음)
• https://github.com/AssemblyScript/assemblyscript

여기에서 합계를 구하려면 텍스트 속성을 "병합"할 수 있는 방법이 있습니다.

코드는 주로 버퍼 데이터에 대한 메모리를 절약한다는 아이디어에 의해 주도됩니다(런타임은 문제가 될 것이며, 아직 테스트되지는 않았습니다). 특히 전경과 배경에 대해 RGB가 있는 텍스트 속성(한 번 지원됨)은 xterm.js가 셀 레이아웃별로 현재 셀에 의해 많은 메모리를 먹게 만들 것입니다. 이 코드는 속성에 대한 크기 조정 가능한 참조 계산 아틀라스를 사용하여 이를 우회하려고 합니다. 단일 터미널은 거의 1백만 개 이상의 셀을 보유할 수 없으므로 모든 셀이 다른 경우 아틀라스가 1M * entry_size 증가하므로 이것은 옵션이 아닙니다.

셀 자체는 속성 아틀라스의 인덱스를 보유하기만 하면 됩니다. 셀 변경 시 이전 인덱스를 참조 해제하고 새 인덱스를 참조해야 합니다. 아틀라스 인덱스는 터미널 개체의 속성 속성을 대체하고 SGR에서 자체적으로 변경됩니다.

아틀라스는 현재 텍스트 속성만 다루지만 필요한 경우 모든 셀 속성으로 확장될 수 있습니다. 현재 터미널 버퍼가 속성 데이터에 대해 2개의 32비트 숫자(현재 버퍼 디자인에서 RGB가 있는 4개)를 보유하는 동안 아틀라스는 이를 단 하나의 32비트 숫자로 줄입니다. 아틀라스 항목도 추가로 포장할 수 있습니다.

interface TextAttributes {
    flags: number;
    foreground: number;
    background: number;
}

const enum AtlasEntry {
    FLAGS = 1,
    FOREGROUND = 2,
    BACKGROUND = 3
}

class TextAttributeAtlas {
    /** data storage */
    private data: Uint32Array;
    /** flag lookup tree, not happy with that yet */
    private flagTree: any = {};
    /** holds freed slots */
    private freedSlots: number[] = [];
    /** tracks biggest idx to shortcut new slot assignment */
    private biggestIdx: number = 0;
    constructor(size: number) {
        this.data = new Uint32Array(size * 4);
    }
    private setData(idx: number, attributes: TextAttributes): void {
        this.data[idx] = 0;
        this.data[idx + AtlasEntry.FLAGS] = attributes.flags;
        this.data[idx + AtlasEntry.FOREGROUND] = attributes.foreground;
        this.data[idx + AtlasEntry.BACKGROUND] = attributes.background;
        if (!this.flagTree[attributes.flags])
            this.flagTree[attributes.flags] = [];
        if (this.flagTree[attributes.flags].indexOf(idx) === -1)
            this.flagTree[attributes.flags].push(idx);
    }

    /**
     * convenient method to inspect attributes at slot `idx`.
     * For better performance atlas idx and AtlasEntry
     * should be used directly to avoid number conversions.
     * <strong i="10">@param</strong> {number} idx
     * <strong i="11">@return</strong> {TextAttributes}
     */
    getAttributes(idx: number): TextAttributes {
        return {
            flags: this.data[idx + AtlasEntry.FLAGS],
            foreground: this.data[idx + AtlasEntry.FOREGROUND],
            background: this.data[idx + AtlasEntry.BACKGROUND]
        };
    }

    /**
     * Returns a slot index in the atlas for the given text attributes.
     * To be called upon attributes changes, e.g. by SGR.
     * NOTE: The ref counter is set to 0 for a new slot index, thus
     * values will get overwritten if not referenced in between.
     * <strong i="12">@param</strong> {TextAttributes} attributes
     * <strong i="13">@return</strong> {number}
     */
    getSlot(attributes: TextAttributes): number {
        // find matching attributes slot
        const sameFlag = this.flagTree[attributes.flags];
        if (sameFlag) {
            for (let i = 0; i < sameFlag.length; ++i) {
                let idx = sameFlag[i];
                if (this.data[idx + AtlasEntry.FOREGROUND] === attributes.foreground
                    && this.data[idx + AtlasEntry.BACKGROUND] === attributes.background) {
                    return idx;
                }
            }
        }
        // try to insert into a previously freed slot
        const freed = this.freedSlots.pop();
        if (freed) {
            this.setData(freed, attributes);
            return freed;
        }
        // else assign new slot
        for (let i = this.biggestIdx; i < this.data.length; i += 4) {
            if (!this.data[i]) {
                this.setData(i, attributes);
                if (i > this.biggestIdx)
                    this.biggestIdx = i;
                return i;
            }
        }
        // could not find a valid slot --> resize storage
        const data = new Uint32Array(this.data.length * 2);
        for (let i = 0; i < this.data.length; ++i)
            data[i] = this.data[i];
        const idx = this.data.length;
        this.data = data;
        this.setData(idx, attributes);
        return idx;
    }

    /**
     * Increment ref counter.
     * To be called for every terminal cell, that holds `idx` as text attributes.
     * <strong i="14">@param</strong> {number} idx
     */
    ref(idx: number): void {
        this.data[idx]++;
    }

    /**
     * Decrement ref counter. Once dropped to 0 the slot will be reused.
     * To be called for every cell that gets removed or reused with another value.
     * <strong i="15">@param</strong> {number} idx
     */
    unref(idx: number): void {
        this.data[idx]--;
        if (!this.data[idx]) {
            let treePart = this.flagTree[this.data[idx + AtlasEntry.FLAGS]];
            treePart.splice(treePart.indexOf(this.data[idx]), 1);
        }
    }
}

let atlas = new TextAttributeAtlas(2);
let a1 = atlas.getSlot({flags: 12, foreground: 13, background: 14});
atlas.ref(a1);
// atlas.unref(a1);
let a2 = atlas.getSlot({flags: 12, foreground: 13, background: 15});
atlas.ref(a2);
let a3 = atlas.getSlot({flags: 13, foreground: 13, background: 16});
atlas.ref(a3);
let a4 = atlas.getSlot({flags: 13, foreground: 13, background: 16});
console.log(atlas);
console.log(a1, a2, a3, a4);
console.log('a1', atlas.getAttributes(a1));
console.log('a2', atlas.getAttributes(a2));
console.log('a3', atlas.getAttributes(a3));
console.log('a4', atlas.getAttributes(a4));

편집하다:
런타임 패널티는 거의 0입니다. ls -lR /usr/lib 사용한 벤치마크의 경우 ~2.3초의 총 런타임에 1밀리초 미만을 추가합니다. 흥미로운 참고 사항 - 이 명령은 5MB 데이터 출력을 위해 64개 미만의 다른 텍스트 속성 슬롯을 설정하고 완전히 구현되면 20MB 이상을 절약합니다.

버퍼에 대한 몇 가지 변경 사항을 테스트하기 위해 프로토타입 PR을 만들었습니다(변경 사항에 대한 일반적인 아이디어는 https://github.com/xtermjs/xterm.js/pull/1528#issue-196949371 참조).

• PR #1528 : 속성 아틀라스
• PR #1529 : 버퍼에서 wcwidth 및 charCode 제거
• PR #1530 : 버퍼의 문자열을 코드포인트/셀 스토리지 인덱스 값으로 교체

@jerch "아틀라스"가 항상 "텍스처 아틀라스"를 의미하도록 아틀라스라는 단어를 멀리하는 것이 좋습니다. 스토어나 캐시 같은 것이 더 나을까요?

오, "캐시"는 괜찮습니다.

테스트베드 PR은 끝났습니다. 다음 대략적인 요약의 배경을 얻으려면 PR 댓글도 살펴보십시오.

제안:

1. 단일 터미널 셀의 스타일을 지정하는 데 필요한 모든 것을 담기 위해 AttributeCache 를 구축합니다. 트루 컬러 사양도 포함할 수 있는 초기 참조 카운팅 버전은 #1528을 참조하십시오. 여러 터미널 앱에서 추가 메모리를 저장해야 하는 경우 다른 터미널 인스턴스 간에 캐시를 공유할 수도 있습니다.
2. 짧은 터미널 콘텐츠 데이터 문자열을 보유하기 위해 StringStorage 를 빌드합니다. #1530의 버전은 포인터 의미를 "오버로드"하여 단일 문자 문자열을 저장하는 것을 방지합니다. wcwidth 는 여기로 옮겨야 합니다.
3. 현재 CharData 를 [number, string, number, number] 에서 [number, number] 축소합니다. 여기서 숫자는 다음에 대한 포인터(인덱스 번호)입니다.
   
   
   
   • AttributeCache 항목
   
   
   • StringStorage 항목
   
   

속성은 많이 변경되지 않을 것이므로 단일 32비트 숫자는 시간이 지남에 따라 많은 메모리를 절약합니다. StringStorage 포인터는 단일 문자에 대한 실제 유니코드 코드포인트이므로 CharData 의 code 항목으로 사용할 수 있습니다. 실제 문자열은 StringStorage.getString(idx) 로 액세스할 수 있습니다. 네번째 필드 wcwidth 의 CharData 액세스 할 수 StringStorage.wcwidth(idx) (아직 구현되지 않음). 치우는에서 거의 런타임 벌금이 code 과 wcwidth 에서 CharData (# 1529에서 테스트가).

1. 축소된 CharData 를 고밀도 Int32Array 기반 버퍼 구현으로 이동합니다. 스텁 클래스(완전한 기능과는 거리가 멀음)로 #1530에서 테스트한 결과 최종 이점은 다음과 같습니다.
   
   
   
   • 터미널 버퍼의 80% 더 작은 메모리 공간(5.5MB에서 0.75MB로)
   
   
   • 약간 더 빠름(아직 테스트할 수 없음, 20% - 30% 속도 향상 예상)
   
   
   • 편집: 훨씬 빠름 - ls -lR /usr/lib 스크립트 런타임이 1.3초로 떨어졌습니다(마스터는 2.1초임). 이전 버퍼는 커서 처리를 위해 여전히 활성화되어 있습니다. 제거되면 런타임이 1초 미만으로 떨어질 것으로 예상됩니다.
   
   

단점 - 4단계는 버퍼 인터페이스에서 약간의 재작업이 필요하기 때문에 상당히 많은 작업입니다. 그러나 이봐 - RAM의 80%를 절약하고 여전히 런타임 성능을 얻는 데는 큰 문제가 되지 않습니까? :웃다:

내가 우연히 발견한 또 다른 문제가 있습니다. 바로 현재 빈 셀 표현입니다. Imho a cell은 3가지 상태를 가질 수 있습니다.

• 비어 있음 : 초기 셀 상태, 아직 아무것도 기록되지 않았거나 내용이 삭제되었습니다. 너비가 1이지만 내용이 없습니다. 현재 blankLine 및 eraseChar 에서 사용되지만 내용으로 공백 이 있습니다.
• null : 시각적 표현을 위한 너비가 없음을 나타내는 전체 너비 char 뒤의 셀입니다.
• normal : 셀이 일부 콘텐츠를 보유하고 시각적 너비가 있습니다(1 또는 2, 실제 grapheme/bidi 항목을 지원하면 더 커질 수 있지만 아직 확실하지 않음 lol).

여기서 내가 볼 수 있는 문제는 빈 셀이 공백이 삽입된 일반 셀과 구별되지 않고 버퍼 수준(동일한 내용, 동일한 너비)에서 동일하게 보입니다. 나는 렌더러/출력 코드를 작성하지 않았지만 이것이 출력 프론트에서 어색한 상황으로 이어질 것으로 예상합니다. 특히 줄의 오른쪽 끝을 처리하는 것이 번거로울 수 있습니다.
15개의 열이 있는 터미널, 먼저 일부 문자열 출력이 래핑되었습니다.

1: 'H', 'e', 'l', 'l', 'o', ' ', 't', 'e', 'r', 'm', 'i', 'n', 'a', 'l', ' '
2: 'w', 'o', 'r', 'l', 'd', '!', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' '

ls 있는 폴더 목록과 비교:

1: 'R', 'e', 'a', 'd', 'm', 'e', '.', 'm', 'd', ' ', ' ', ' ', ' ', ' ', ' '
2: 'f', 'i', 'l', 'e', 'A', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' '

첫 번째 예는 'terminal'이라는 단어 뒤에 실제 공백 을 포함하고, 두 번째 예는 'Readme.md' 뒤의 셀을 건드리지 않습니다. 버퍼 수준에서 표현되는 방식은 표준 케이스가 화면에 터미널 출력으로 물건을 인쇄하는 데 완벽하지만(어쨌든 방을 가져와야 함), 마우스 선택과 같은 콘텐츠 문자열을 처리하려는 도구의 경우 또는 리플 로우 관리자는 더 이상 공간이 어디에서 왔는지 명확하지 않습니다.

이것은 다음 질문으로 이어집니다. 줄의 실제 내용 길이(왼쪽에서 무언가를 포함하는 셀의 양)를 결정하는 방법은 무엇입니까? 간단한 접근 방식은 오른쪽에서 빈 셀을 세는데, 위의 이중 의미는 이것을 결정하기 어렵게 만듭니다.

제안:
이것은 빈 셀에 다른 자리 표시자를 사용하여 쉽게 고칠 수 있습니다(예: 제어 문자 또는 빈 문자열). 필요한 경우 렌더링 프로세스에서 교체합니다. 화면 렌더러는 이러한 셀을 전혀 처리할 필요가 없을 수도 있기 때문에(출력이 생성되는 방식에 따라 다름) 이로부터 이점을 얻을 수도 있습니다.

Btw, 위의 래핑된 문자열의 경우 isWrapped 문제도 발생합니다. 이는 리플로우 크기 조정 또는 올바른 복사 및 붙여넣기 선택 처리에 필수적입니다. Imho 우리는 그것을 제거 할 수 없지만 at보다 더 잘 통합해야합니다.

@jerch 인상적인 작품! : 스마일 :

1 단일 터미널 셀의 스타일을 지정하는 데 필요한 모든 것을 보유하는 AttributeCache를 구축합니다. 트루 컬러 사양도 포함할 수 있는 초기 참조 카운팅 버전은 #1528을 참조하십시오. 여러 터미널 앱에서 추가 메모리를 저장해야 하는 경우 다른 터미널 인스턴스 간에 캐시를 공유할 수도 있습니다.

#1528에 대한 의견을 작성했습니다.

2 짧은 터미널 콘텐츠 데이터 문자열을 보관할 StringStorage를 구축합니다. #1530의 버전은 포인터 의미를 "오버로드"하여 단일 문자 문자열을 저장하는 것을 방지합니다. wcwidth를 여기로 옮겨야 합니다.

#1530에 대한 의견을 작성했습니다.

4 축소된 CharData를 밀도가 높은 Int32Array 기반 버퍼 구현으로 이동합니다. 스텁 클래스(완전한 기능과는 거리가 멀음)로 #1530에서 테스트한 결과 최종 이점은 다음과 같습니다.

아직 이 아이디어가 완전히 팔리지는 않았지만, 우리가 리플로우를 구현할 때 우리를 힘들게 할 것이라고 생각합니다. 이 각 단계를 순서대로 수행할 수 있으므로 3단계를 완료한 후 일이 어떻게 진행되는지 확인하고 이 작업을 수행하는 것이 타당한지 확인할 수 있습니다.

내가 우연히 발견한 또 다른 문제가 있습니다. 바로 현재 빈 셀 표현입니다. Imho 세포는 3개의 상태를 가질 수 있습니다

다음은 이 https://github.com/xtermjs/xterm.js/issues/1286 , :+1: 공백 셀과 "빈" 셀을 구별하는 버그의 예입니다.

Btw, 위의 래핑된 문자열의 경우에도 isWrapped 문제가 발생합니다. 이는 리플로우 크기 조정 또는 올바른 복사 및 붙여넣기 선택 처리에 필수적입니다. Imho 우리는 그것을 제거 할 수 없지만 at보다 더 잘 통합해야합니다.

CircularList에는 래핑되지 않은 행만 포함되므로 https://github.com/xtermjs/xterm.js/issues/622 를 처리할 때 isWrapped 사라지는 것을 봅니다.

아직 이 아이디어가 완전히 팔리지는 않았지만, 우리가 리플로우를 구현할 때 우리를 힘들게 할 것이라고 생각합니다. 이 각 단계를 순서대로 수행할 수 있으므로 3단계를 완료한 후 일이 어떻게 진행되는지 확인하고 이 작업을 수행하는 것이 타당한지 확인할 수 있습니다.

예, 저는 당신과 함께합니다(이 완전히 다른 접근 방식을 가지고 노는 것은 여전히 ​​재미있습니다). 1과 2는 선택될 수 있고 3은 1 또는 2에 따라 적용될 수 있습니다. 4는 선택 사항이며 현재 버퍼 레이아웃을 고수할 수 있습니다. 메모리 절약은 다음과 같습니다.

1. 1 + 2 + 3 in CircularList : 50% 절약(~5.5MB 중 ~2.8MB)
2. 1 + 2 + 3 + 4 중간 - 행 데이터를 유형이 지정된 배열에 넣지만 행 인덱스 액세스를 유지: 82%(~0.9MB) 절약
3. 포인터 산술이 포함된 1 + 2 + 3 + 4 완전 밀도 배열: 87% 절약(~0.7MB)

1. 구현하기가 매우 쉽습니다. 더 큰 scrollBack을 사용하는 메모리 동작은 https://github.com/xtermjs/xterm.js/pull/1530#issuecomment -403542479에 표시된 것처럼 여전히 나쁜 스케일링을 표시하지만 덜 유독한 수준입니다.
2. 구현하기가 약간 더 어렵지만(라인 수준에서 더 많은 간접 참조가 필요함) Buffer 의 상위 API를 그대로 유지하는 것이 가능합니다. Imho 옵션 - 큰 메모리를 저장하고 통합하기 쉽습니다.
3. 구현하기 어려운 옵션 2보다 5% 더 많은 메모리 저장은 모든 API를 변경하므로 말 그대로 전체 코드 기반을 변경합니다. 학문적 관심이나 지루한 비오는 날을 위해 임호를 더 구현합니다.

@Tyriar 웹 어셈블리 사용을 위해 녹으로 몇 가지 추가 테스트를 수행하고 파서를 다시 작성했습니다. 내 녹 기술은 아직 더 깊이 들어가지 않았기 때문에 약간 "녹이 슬었습니다". 따라서 다음은 약한 녹 코드의 결과일 수 있습니다. 결과:

• wasm 부분 내에서 데이터 처리가 약간 더 빠릅니다(5 - 10%).
• JS에서 wasm으로의 호출은 약간의 오버헤드를 생성하고 위의 모든 이점을 먹습니다. 실제로는 ~20% 느렸습니다.
• "바이너리"는 JS 상대보다 작을 것입니다(모든 것을 구현하지 않았기 때문에 실제로 측정되지 않았습니다).
• JS <--> wasm 전환을 쉽게 수행하려면 JS 유형을 처리하는 데 일부 bloatcode가 필요합니다(문자열 변환만 수행).
• 브라우저 DOM 및 이벤트에 액세스할 수 없기 때문에 JS에서 wasm으로의 변환을 피할 수 없습니다. 더 이상 성능이 중요하지 않은 핵심 부품에만 사용할 수 있습니다(mem 소비 제외).

전체 핵심 라이브러리를 녹(또는 다른 wasm 가능 언어)으로 다시 작성하지 않으려면 wasm lang imho로 이동하여 아무 것도 얻을 수 없습니다. 요즘 wasm lang의 장점은 대부분이 명시적 메모리 처리를 지원한다는 사실(버퍼 문제를 해결하는 데 도움이 될 수 있음)이고, 단점은 주로 TS/JS 중심 프로젝트에 완전히 다른 언어를 도입한다는 것입니다(코드 추가에 대한 높은 장벽) 그리고 wasm과 JS 랜드 간의 번역 비용.

TL;DR
xterm.js는 DOM 및 이벤트와 같은 일반적인 JS 항목에 광범위하게 적용되어 핵심 부분을 다시 작성하는 경우에도 웹 어셈블리에서 무엇이든 얻을 수 있습니다.

@jerch 좋은 조사 : 스마일 :

JS에서 wasm으로의 호출은 약간의 오버헤드를 생성하고 위의 모든 이점을 먹습니다. 실제로는 ~20% 느렸습니다.

이것은 기본적으로 내 입장을 알려준 모나코의 주요 문제 이기도 했습니다. 가능한 한 ArrayBuffer 작업하는 것이 성능과 단순성(간단한 임플, 진입 장벽) 사이에서 최상의 균형을 제공해야 한다고 생각합니다.

@Tyriar RGB 데이터를 보관할 AttributeStorage를 만들려고 합니다. BST에 대해서는 아직 확실하지 않습니다. 터미널 세션에서 몇 가지 색상 설정만 있는 일반적인 사용 사례의 경우 런타임에 더 나빠질 것입니다. 색상이 주어진 임계값을 초과하면 런타임 드롭인이 될 수 있습니다. 또한 메모리 소비가 다시 많이 증가하지만 속성은 모든 단일 셀과 함께 저장되지 않고 한 번만 저장되기 때문에 여전히 메모리를 절약합니다.
현재 fg 및 bg 256색 값이 8비트가 아닌 9비트 기반인 이유를 알고 있습니까? 추가 비트는 무엇에 사용됩니까? 여기: https://github.com/xtermjs/xterm.js/blob/6691f809069a549b4808cd2e055398d2da15db37/src/InputHandler.ts#L1596
attr 의 현재 비트 레이아웃을 알려주시겠습니까? StringStorage 포인터에 대한 "이중 의미"와 같은 유사한 접근 방식을 사용하면 메모리를 더 절약할 수 있지만 attr 의 MSB는 포인터 구분을 위해 예약되고 다른 용도로는 사용되지 않아야 합니다. 이것은 나중에 추가 속성 플래그를 지원할 가능성을 제한할 수 있습니다( FLAGS 이미 7비트를 사용하기 때문에). 우리는 여전히 올 가능성이 있는 몇 가지 기본 플래그를 놓치고 있습니까?

버퍼라는 용어의 32비트 attr 숫자는 다음과 같이 패킹될 수 있습니다.

# 256 indexed colors
32:       0 (no RGB color)
31..25:   flags (7 bits)
24..17:   fg (8 bits, see question above)
16..9:    bg
8..1:     unused

# RGB colors
32:       1 (RGB color)
31..25:   flags (7 bits)
24..1:    pointer to RGB data (address space is 2^24, which should be sufficient)

이런 식으로 저장소는 두 개의 32비트 숫자로 RGB 데이터를 보유해야 하는 반면 플래그는 attr 숫자에 머무를 수 있습니다.

@jerch 그나저나 제가 이메일을 보냈는데 스팸필터에 또 먹혔나봐요 😛

현재 fg 및 bg 256 색상 값이 8비트가 아닌 9비트 기반인 이유를 알고 있습니까? 추가 비트는 무엇에 사용됩니까?

기본 fg/bg 색상(어두울 수도 밝을 수 있음)에 사용되는 것 같아서 실제로는 257가지 색상입니다.

https://github.com/xtermjs/xterm.js/pull/756/files

attr의 현재 비트 레이아웃을 알려주시겠습니까?

나는 이것이라고 생각한다:

19+:     flags (see `FLAGS` enum)
18..18:  default fg flag
17..10:  256 fg
9..9:    default bg flag
8..1:    256 bg

이전 PR https://github.com/xtermjs/xterm.js/pull/756/files 에서 내가 트루컬러에 대해 알게 된 것을 볼 수 있습니다.

/**
 * Character data, the array's format is:
 * - string: The character.
 * - number: The width of the character.
 * - number: Flags that decorate the character.
 *
 *        truecolor fg
 *        |   inverse
 *        |   |   underline
 *        |   |   |
 *   0b 0 0 0 0 0 0 0
 *      |   |   |   |
 *      |   |   |   bold
 *      |   |   blink
 *      |   invisible
 *      truecolor bg
 *
 * - number: Foreground color. If default bit flag is set, color is the default
 *           (inherited from the DOM parent). If truecolor fg flag is true, this
 *           is a 24-bit color of the form 0xxRRGGBB, if not it's an xterm color
 *           code ranging from 0-255.
 *
 *        red
 *        |       blue
 *   0x 0 R R G G B B
 *      |     |
 *      |     green
 *      default color bit
 *
 * - number: Background color. The same as foreground color.
 */
export type CharData = [string, number, number, number, number];

그래서 이것에는 2개의 깃발이 있었습니다. 하나는 기본 색상(모든 색상 비트를 무시할지 여부)이고 다른 하나는 트루컬러(256 또는 16mil 색상을 수행할지 여부)입니다.

이것은 나중에 추가 속성 플래그를 지원할 가능성을 제한할 수 있습니다(FLAGS는 이미 7비트를 사용하기 때문에). 우리는 여전히 올 가능성이 있는 몇 가지 기본 플래그를 놓치고 있습니까?

예, 예를 들어 https://github.com/xtermjs/xterm.js/issues/580, https://github.com/xtermjs/xterm.js/issues/1145와 같이 추가 플래그를 위한 공간이 필요합니다. 가능하면 최소한 3비트 이상으로 두십시오.

attr 자체 내부의 포인터 데이터 대신 rgb 데이터에 대한 참조를 보유하는 다른 맵이 있을 수 있습니까? mapAttrIdxToRgb: { [idx: number]: RgbData

@Tyriar 죄송합니다. 며칠 동안 온라인 상태가 아니었고 이메일이 스팸 필터에 의해 먹힐까봐 두렵습니다. 다시 보내주시겠습니까? :붉히다:

attrs 저장소에 대한 더 영리한 조회 데이터 구조로 약간 놀았습니다. 공간 및 검색/삽입 런타임과 관련하여 가장 유망한 것은 더 저렴한 대안으로 나무와 건너뛰기 목록입니다. 이론상 ㅋㅋㅋㅋ 실제로 어느 쪽도 나에게 매우 이상해 보이는 간단한 배열 검색을 능가할 수 없습니다(코드 어딘가에 버그가 있습니까?)
나는 테스트 파일을 여기 https://gist.github.com/jerch/ff65f3fb4414ff8ac84a947b3a1eec58에 업로드했습니다. 어레이 대 왼쪽으로 기울어진 적-검정 트리, 최대 10M 항목(거의 완전한 주소 지정 공간)을 테스트합니다. 여전히 어레이는 LLRB에 비해 훨씬 앞서 있지만 손익분기점은 약 10M일 것으로 생각합니다. 내 7년 된 노트북에서 테스트했으며 누군가가 테스트할 수도 있고 더 잘 테스트할 수 있습니다. impl/tests의 몇 가지 버그를 알려주세요.

다음은 몇 가지 결과입니다(연속 번호 포함):

prefilled             time for inserting 1000 * 1000 (summed up, ms)
items                 array        LLRB
100-10000             3.5 - 5      ~13
100000                ~12          ~15
1000000               8            ~18
10000000              20-25        21-28

나를 정말 놀라게 한 것은 선형 배열 검색이 하위 영역에서 전혀 성장을 보여주지 않는다는 사실이며 ~4ms에서 최대 10k 항목이 안정적이라는 것입니다(캐시 관련일 수 있음). 10M 테스트는 둘 다 예상보다 더 나쁜 런타임을 보여줍니다. 아마도 mem 페이징으로 인한 것일 수 있습니다. 아마도 JS는 JIT와 모든 opt/deopts가 발생하는 기계에서 멀리 떨어져 있지만 여전히 복잡성 단계를 제거할 수 없다고 생각합니다(LLRB가 단일 _n_에서 무거워 보이므로 O( n) 대 O(logn) 위쪽)

무작위 데이터의 Btw는 그 차이가 훨씬 더 나쁩니다.

기본 fg/bg 색상(어두울 수도 밝을 수 있음)에 사용되는 것 같아서 실제로는 257가지 색상입니다.

이것은 8개의 팔레트 색상 중 하나에서 SGR 39 또는 SGR 49 를 구별하는 것입니까?

attr 자체 내부의 포인터 데이터 대신 rgb 데이터에 대한 참조를 보유하는 다른 맵이 있을 수 있습니까? mapAttrIdxToRgb: { [idx: 번호]: RgbData

이것은 추가 메모리 사용과 함께 또 다른 간접 참조를 소개합니다. 위의 테스트를 통해 플래그를 항상 attr에 유지하는 것과 RGB 데이터와 함께 스토리지에 저장하는 것의 차이점도 테스트했습니다. 1M 항목의 경우 차이가 ~0.5ms이므로 이 복잡한 속성 설정을 사용하지 않고 대신 RGB가 설정되면 플래그를 저장소에 복사합니다. 그래도 직접 속성 대 포인터 사이의 32비트 구별을 선택합니다. 이렇게 하면 RGB가 아닌 셀에 대한 저장이 전혀 방지되기 때문입니다.

또한 fg/bg에 대한 기본 8개의 팔레트 색상이 현재 버퍼에서 충분히 표현되지 않는다고 생각합니다. 이론적으로 터미널은 다음 색상 모드를 지원해야 합니다.

1. SGR 39 + SGR 49 fg/bg의 기본 색상(사용자 정의 가능)
2. SGR 30-37 + SGR 40-47 fg/bg용 8가지 낮은 색상 팔레트(사용자 정의 가능)
3. SGR 90-97 + SGR 100-107 fg/bg용 8가지 하이 컬러 팔레트(사용자 정의 가능)
4. SGR 38;5;n + SGR 48;5;n fg/bg를 위한 256개의 인덱스 팔레트(사용자 정의 가능)
5. SGR 38;2;r;g;b + SGR 48;2;r;g;b fg/bg용 RGB(사용자 정의 불가)

옵션 2.) 및 3.)을 단일 바이트로 병합할 수 있습니다(단일 16색 fg/bg 팔레트로 처리). 4.)는 2바이트, 5.)는 마지막으로 6바이트를 더 사용합니다. 색상 모드를 나타내기 위해서는 여전히 약간의 비트가 필요합니다.
이를 버퍼 수준에 반영하려면 다음이 필요합니다.

bits        for
2           fg color mode (0: default, 1: 16 palette, 2: 256, 3: RGB)
2           bg color mode (0: default, 1: 16 palette, 2: 256, 3: RGB)
8           fg color for 16 palette and 256
8           bg color for 16 palette and 256
10          flags (currently 7, 3 more reserved for future usage)
----
30

따라서 32비트 숫자의 30비트가 필요하고 2비트는 다른 용도로 사용할 수 있습니다. 32번째 비트는 비 RGB 셀에 대한 저장을 생략하는 포인터 대 직접 속성 플래그를 보유할 수 있습니다.

또한 구현 세부 사항을 외부에 노출하지 않도록 attr 액세스를 편리한 클래스로 마무리하는 것이 좋습니다(위의 테스트 파일 참조, 이를 달성하기 위한 초기 버전의 TextAttributes 클래스가 있음).

죄송합니다. 며칠 동안 온라인 상태가 아니어서 스팸 필터에 이메일이 걸린 것 같습니다. 다시 보내주시겠습니까?

화내다

오 btw 배열 대 llrb 검색에 대한 위의 숫자는 쓰레기입니다. 최적화 프로그램이 for 루프에서 이상한 작업을 수행하여 망쳐 졌다고 생각합니다. 약간 다른 테스트 설정을 사용하면 훨씬 더 일찍 성장하는 O(n) 대 O(log n)을 명확하게 보여줍니다(1000개의 요소가 미리 채워진 상태에서 트리로 이미 더 빠름).

현재 상태:

• [x] 다중 버퍼 구현을 허용하는 리팩터링 https://github.com/xtermjs/xterm.js/pull/1632
• [x] TypedArray 기반 버퍼 구현 추가 https://github.com/xtermjs/xterm.js/pull/1641
• [ ] 스크롤백 끝에서 잘린 배열 재사용 https://github.com/xtermjs/xterm.js/pull/1731
• [ ] 이전 버퍼 구현을 제거하고(새 버전이 안정적인지 확인한 후) 유형이 지정된 배열 버퍼에 대한 액세스를 개선하여 불필요한 개체 사이를 생성하지 않도록 합니다. https://github.com/xtermjs/xterm.js/blob/ 8d16bb6ea2e90312b0efb28bee3f39d3995a906f/src/BufferLine.ts#L153 -L162

후에:

• 트루 컬러 https://github.com/xtermjs/xterm.js/issues/484

상당히 간단한 최적화 중 하나는 배열 배열을 단일 배열로 병합하는 것입니다. 즉, BufferLine of _N_ 열 대신 _data _N_ CharData 셀의 배열이 있고 여기서 각 CharData 는 4개의 배열입니다. _4*N_ 요소의 배열입니다. 이것은 _N_ 배열의 개체 오버헤드를 제거합니다. 또한 캐시 지역성을 향상시키므로 더 빨라야 합니다. 단점은 약간 더 복잡하고 못생긴 코드이지만 그만한 가치가 있는 것 같습니다.

이전 의견에 대한 후속 조치로 각 셀에 대해 _data 배열에서 다양한 수의 요소를 사용하는 것을 고려해 볼 가치가 있는 것 같습니다. 즉, 상태 저장 표현입니다. 임의의 위치 변경은 비용이 더 많이 들지만, 특히 간단한 어레이가 캐시 지역성에 최적화되어 있기 때문에 라인 시작부터 선형 스캐닝이 매우 빠를 수 있습니다. 일반적인 순차 출력은 렌더링과 마찬가지로 빠릅니다.

공간을 줄이는 것 외에도 셀당 다양한 요소 수의 이점은 유연성이 증가한다는 것입니다. 추가 속성(예: 24비트 색상), 특정 셀 또는 범위에 대한 주석, 글리프 또는
중첩된 DOM 요소

@PerBothner 당신의 아이디어에 대한 Thx! 예, 이미 포인터 산술로 단일 밀집 배열 레이아웃을 테스트했으며 최고의 메모리 사용률을 보여줍니다. 크기 조정과 관련하여 문제가 발생합니다. 기본적으로 전체 메모리 청크를 다시 작성(복사)하거나 더 큰 청크로 빠르게 복사하고 부분을 재정렬하는 것을 의미합니다. 이것은 꽤 특급입니다. 그리고 imho는 mem 절약에 의해 정당화되지 않습니다(위에 나열된 일부 플레이그라운드 PR에서 테스트, 절약은 새로운 버퍼 라인 구현과 비교하여 약 10% 정도였습니다).

두 번째 의견에 대해 - 래핑된 줄을 더 쉽게 처리할 수 있도록 이미 논의했습니다. 지금은 새로운 버퍼 레이아웃에 대해 행 X 열 접근 방식을 사용하고 먼저 완료하기로 결정했습니다. 리플로우 크기 조정 구현을 수행하면 이 문제를 다시 해결해야 한다고 생각합니다.

버퍼에 추가 항목 추가: 현재 대부분의 다른 터미널이 수행하는 작업을 수행합니다. 커서 진행은 데이터가 어떻게 배치되어야 하는지 pty/termios의 아이디어와 호환되도록 보장하는 wcwidth 의해 결정됩니다. 이것은 기본적으로 서로게이트 쌍 및 문자 결합과 같은 것만 버퍼 수준에서 처리한다는 것을 의미합니다. 다른 "상위 수준" 결합 규칙은 렌더러의 캐릭터 결합자가 적용할 수 있습니다(현재 합자에 대해 https://github.com/xtermjs/xterm-addon-ligatures에서 사용). 초기 버퍼 수준에서 유니코드 자소를 지원하기 위해 PR을 열었지만 대부분의 pty 백엔드에는 이에 대한 개념이 없기 때문에(전혀 존재합니까?) 이상한 char 대기업으로 끝날 것이기 때문에 그 단계에서는 이 작업을 수행할 수 없다고 생각합니다. . 실제 BIDI 지원도 마찬가지입니다. 커서/셀 움직임을 그대로 유지하려면 렌더러 단계에서 grapheme과 BIDI가 더 잘 수행된다고 생각합니다.

셀에 연결된 DOM 노드에 대한 지원은 정말 흥미롭게 들립니다. 저는 그 아이디어가 좋습니다. 현재 다른 렌더러 백엔드(DOM, 캔버스 2D 및 새로운 빛나는 webgl 렌더러)가 있기 때문에 직접적인 접근 방식으로는 불가능하지만 기본적으로 지원되지 않는 위치에 오버레이를 배치하여 모든 렌더러에 대해 이것이 여전히 달성될 수 있다고 생각합니다(DOM 렌더러만 직접 할 수 있습니다). 우리는 물건과 그 크기와 렌더러가 더러운 작업을 할 수 있음을 알리기 위해 버퍼 수준에서 일종의 API가 필요합니다. 나는 이것을 별도의 문제로 논의/추적해야 한다고 생각합니다.

자세한 답변 감사합니다.

_"크기 조정과 관련하여 문제가 발생합니다. 기본적으로 전체 메모리 청크를 다시 작성(복사)하거나 더 큰 청크로 빠르게 복사하고 부분을 재정렬하는 것을 의미합니다."_

크기 조정 시 _N_ 요소가 아닌 _4*N_ 요소를 복사해야 한다는 뜻입니까?

배열이 논리적(래핑되지 않은) 행에 대한 모든 셀을 포함하는 것이 합리적일 수 있습니다. 예를 들어 180자 행과 80열 너비의 터미널을 가정합니다. 이 경우 3개의 BufferLine 인스턴스가 모두 동일한 _4*180_-element _data 버퍼를 공유할 수 있지만 각 BufferLine 에는 시작 오프셋도 포함됩니다.

글쎄, 나는 [cols] x [rows] x [needed single cell space] 의해 구축된 하나의 큰 배열에 모든 것을 가지고 있었다. 따라서 기본적으로 여전히 주어진 높이와 너비로 "캔버스"로 작동했습니다. 이것은 정상적인 입력 흐름에 대해 실제로 메모리 효율적이고 빠르지만 insertCell / deleteCell 가 호출되자마자(크기 조정으로 수행됨) 작업이 발생하는 위치 뒤에 있는 전체 메모리 옮겨야 할 것입니다. 작은 스크롤백(<10k)의 경우 이것도 문제가 되지 않습니다. 실제로 >100k 라인에 대한 쇼스토퍼입니다.
현재 형식화된 배열 impl은 여전히 ​​이러한 이동을 수행해야 하지만 메모리 내용을 줄 끝까지 이동하기만 하면 되므로 독성이 덜합니다.
비용이 많이 드는 이동을 피하기 위해 다른 레이아웃에 대해 생각했습니다. 말도 안되는 메모리 이동을 저장하기 위한 기본 필드는 실제로 스크롤백을 "핫 터미널 행"(가장 최근 terminal.rows )에서 분리하는 것입니다. 커서 점프 및 삽입/삭제에 의해 변경됩니다.

여러 버퍼 라인 객체가 기본 메모리를 공유하는 것은 래핑 문제를 해결하는 흥미로운 아이디어입니다. 명시적인 참조 처리 등을 도입하지 않고 이것이 어떻게 안정적으로 작동할 수 있는지 아직 확실하지 않습니다. 다른 버전에서는 명시적 메모리 처리로 모든 작업을 수행하려고 했지만 ref 카운터는 실제 쇼스토퍼였으며 GC 랜드에서 잘못되었다고 느꼈습니다. (프리미티브는 #1633 참조)

편집: Btw 명시적 메모리 처리는 현재의 "라인당 메모리" 접근 방식과 동등했습니다. 더 나은 캐시 지역성으로 인해 더 나은 성능을 기대했는데, 약간 더 많은 경험치가 먹힌 것 같습니다. JS 추상화에서 mem 처리.

셀에 연결된 DOM 노드에 대한 지원은 정말 흥미롭게 들립니다. 저는 그 아이디어가 좋습니다. 현재 다른 렌더러 백엔드(DOM, 캔버스 2D 및 새로운 빛나는 webgl 렌더러)가 있기 때문에 직접적인 접근 방식으로는 불가능하지만 기본적으로 지원되지 않는 위치에 오버레이를 배치하여 모든 렌더러에 대해 이것이 여전히 달성될 수 있다고 생각합니다(DOM 렌더러만 직접 할 수 있습니다).

주제에서 조금 벗어나지만 결국 캔버스 렌더 레이어와 유사하게 작동하는 뷰포트 내의 셀과 연결된 DOM 노드를 갖게 됩니다. 그렇게 하면 소비자는 HTML과 CSS를 사용하여 셀을 "장식"할 수 있고 캔버스 API에 들어갈 필요가 없습니다.

배열이 논리적(래핑되지 않은) 행에 대한 모든 셀을 포함하는 것이 합리적일 수 있습니다. 예를 들어 180자 행과 80열 너비의 터미널을 가정합니다. 이 경우 3개의 BufferLine 인스턴스가 모두 동일한 4*180 요소 _data 버퍼를 공유할 수 있지만 각 BufferLine에는 시작 오프셋도 포함됩니다.

위에서 언급한 리플로우에 대한 계획은 https://github.com/xtermjs/xterm.js/issues/622#issuecomment -375403572에 캡처되어

조밀한 배열 접근 방식을 사용하는 것이 우리가 볼 수 있는 것일 수 있지만 이러한 배열에서 줄 바꿈되지 않은 줄 바꿈을 관리하는 데 추가 오버헤드와 행이 스크롤백 버퍼 그럼에도 불구하고 #791이 완료되고 #622를 볼 때까지 이러한 변경 사항을 조사해서는 안 된다고 생각합니다.

PR #1796을 사용하면 파서는 다른 입력 인코딩에 대한 서버의 추가 최적화를 위한 문을 여는 형식화된 배열 지원을 받습니다.

지금은 JS 문자열로 앞뒤로 쉽게 변환할 수 있기 때문에 Uint16Array 사용하기로 결정했습니다. 이것은 기본적으로 게임을 UCS2/UTF16으로 제한하는 반면 현재 버전의 파서는 UTF32도 처리할 수 있습니다(UTF8은 지원되지 않음). 유형이 지정된 배열 기반 터미널 버퍼는 현재 UTF32용으로 레이아웃되어 있으며 UTF16 --> UTF32 변환은 InputHandler.print 에서 수행됩니다. 여기에서 몇 가지 방향이 가능합니다.

• 모든 UTF16을 만드십시오. 따라서 터미널 버퍼도 UTF16으로 바꾸십시오.
  예, 여기에서 어느 길을 택할지 아직 정하지 않았지만 여러 버퍼 레이아웃을 테스트하고 32비트 숫자는 실제 문자 코드 + wcwidth + 가능한 결합 오버플로(완전히 다르게 처리됨)를 저장할 수 있는 충분한 공간을 제공하지만 16비트는 그렇게 할 수 없다는 결론에 도달했습니다. 귀중한 charcode 비트를 희생하지 않고. wcwidth는 유니코드 코드 포인트에서 작동하기 때문에 UTF16 버퍼를 사용하더라도 여전히 UTF32 변환을 수행해야 합니다. 또한 UTF16 기반 버퍼는 낮은 문자 코드에 대해 더 많은 메모리를 절약할 수 있으며 실제로 BMP 평면 문자 코드보다 높은 경우는 거의 발생하지 않습니다. 이것은 아직 조사가 필요합니다.
• 파서를 UTF32로 만들기
  아주 간단합니다. 모든 유형이 지정된 배열을 32비트 변형으로 바꾸면 됩니다. 단점 - UTF16에서 UTF32로의 변환은 사전에 수행되어야 합니다. 즉, 문자 코드 > 255로 구성되지 않는 이스케이프 시퀀스도 포함하여 전체 입력이 변환됩니다.
• wcwidth UTF16 호환 가능
  예, UTF16이 터미널 버퍼에 더 적합한 것으로 판명되면 이 작업을 수행해야 합니다.

UTF8 정보: 파서는 현재 기본 UTF8 시퀀스를 처리할 수 없습니다. 주로 중간 문자가 C1 제어 문자와 충돌하기 때문입니다. 또한 UTF8은 추가 중간 상태와 함께 적절한 스트림 처리가 필요합니다. 불쾌하고 imho가 파서에 추가되어서는 안 됩니다. UTF8은 사전에 더 잘 처리될 것이며 아마도 모든 곳에서 보다 쉬운 코드 포인트 처리를 위해 UTF32로의 변환 권한이 있을 것입니다.

가능한 UTF8 입력 인코딩 및 내부 버퍼 레이아웃과 관련하여 대략적인 테스트를 수행했습니다. 전체 런타임에 대한 캔버스 렌더러의 훨씬 더 높은 영향을 배제하기 위해 곧 출시될 webgl 렌더러로 이를 수행했습니다. 내 ls -lR /usr/lib 벤치마크를 사용하면 다음과 같은 결과를 얻을 수 있습니다.

• 현재 마스터 + webgl 렌더러:
  

• 놀이터 분기는 #1796, #1811 및 webgl 렌더러의 일부를 적용합니다.
  

플레이그라운드 브랜치는 구문 분석 및 저장을 수행하기 전에 UTF8에서 UTF32로 초기 변환을 수행합니다(변환 추가 ~ 30ms). 속도 향상은 주로 입력 흐름 중 2가지 핫 기능인 EscapeSequenceParser.parse (120ms 대 35ms) 및 InputHandler.print (350ms 대 75ms)에 의해 얻습니다. 둘 다 .charCodeAt 호출을 저장하여 형식화된 배열 스위치에서 많은 이점을 얻습니다.
또한 이 결과를 UTF16 중간 유형 배열과 비교했습니다. EscapeSequenceParser.parse 는 약간 더 빠르지만(~ 25ms) InputHandler.print 는 wcwidth 에서 필요한 대리 쌍 및 코드 포인트 조회로 인해 뒤쳐집니다
또한 나는 이미 시스템이 ls 데이터를 제공할 수 있는 한계에 이르렀습니다(SSD가 있는 i7) - 획득한 속도 향상은 실행을 더 빠르게 만드는 대신 유휴 시간을 추가합니다.

요약:
Imho 우리가 얻을 수 있는 가장 빠른 입력 처리는 버퍼 표현을 위한 UTF8 전송 + UTF32의 혼합입니다. UTF8 전송은 일반적인 터미널 입력에 대해 최고의 바이트 팩률을 가지며 최대 Terminal.write 버퍼의 여러 레이어를 통해 pty에서 말도 안되는 변환을 제거하지만 UTF32 기반 버퍼는 데이터를 매우 빠르게 저장할 수 있습니다. 후자는 UTF16보다 약간 더 높은 메모리 공간을 제공하는 반면 UTF16은 더 많은 간접 참조가 포함된 더 복잡한 문자 처리로 인해 약간 느립니다.

결론:
지금은 UTF32 기반 버퍼 레이아웃을 사용해야 합니다. 또한 UTF8 입력 인코딩으로 전환하는 것을 고려해야 하지만 통합자에 대한 API 변경 및 의미에 대해 좀 더 생각해야 합니다(electron의 ipc 메커니즘이 BASE64 인코딩 및 JSON 래핑 없이 바이너리 데이터를 처리할 수 없는 것처럼 보임).

향후 트루 컬러 지원을 위한 버퍼 레이아웃:

현재 형식화된 배열 기반 버퍼 레이아웃은 다음과 같습니다(하나의 셀).

|    uint32_t    |    uint32_t    |    uint32_t    |
|      attrs     |    codepoint   |     wcwidth    |

여기서 attrs 에는 필요한 모든 플래그 + 9비트 기반 FG 및 BG 색상이 포함됩니다. codepoint 는 21비트(UTF32의 경우 최대 0x10FFFF) + 1비트를 사용하여 문자를 결합하고 wcwidth 2비트(0-2 범위)를 나타냅니다.

아이디어는 추가 RGB 값을 위한 공간을 만들기 위해 비트를 더 나은 팩률로 재배열하는 것입니다.

• wcwidth 를 codepoint 의 사용되지 않은 상위 ​​비트에 넣습니다.
• 속성을 32비트의 FG 및 BG 그룹으로 분할하고 플래그를 사용하지 않는 비트에 배포합니다.

|             uint32_t             |        uint32_t         |        uint32_t         |
|              content             |            FG           |            BG           |
| comb(1) wcwidth(2) codepoint(21) | flags(8) R(8) G(8) B(8) | flags(8) R(8) G(8) B(8) |

이 접근 방식의 장점은 하나의 인덱스 액세스 및 최대값으로 모든 값에 비교적 저렴하게 액세스할 수 있다는 것입니다. 2비트 연산(및/또는 + 시프트).

메모리 풋프린트는 현재 변형에 대해 안정적이지만 여전히 셀당 12바이트로 상당히 높습니다. 이것은 UTF16 및 attr 간접으로 전환하여 일부 런타임을 희생하여 추가로 최적화할 수 있습니다.

|        uint16_t        |              uint16_t               |
|    BMP codepoint(16)   | comb(1) wcwidth(2) attr pointer(13) |

이제 우리는 셀당 4바이트 + 속성을 위한 약간의 공간으로 줄었습니다. 이제 속성은 다른 셀에도 재활용될 수 있습니다. 야 미션 완수! - 음, 잠시만...

메모리 공간을 비교하면 두 번째 접근 방식이 확실히 유리합니다. 런타임의 경우 런타임을 크게 증가시키는 세 가지 주요 요인이 있습니다.

• attr 간접 참조
  attr 포인터는 다른 데이터 컨테이너에 대한 하나의 추가 메모리 조회가 필요합니다.
• 속성 일치
  두 번째 접근 방식으로 공간을 실제로 절약하려면 주어진 속성을 이미 저장된 속성과 일치시켜야 합니다. 이것은 성가신 작업입니다. 단순히 기존의 모든 값을 살펴보는 직접적인 접근 방식은 저장된 n개의 속성에 대해 O(n)에 있습니다. 내 RB 트리 실험은 여전히 ​​O(log n)에 있는 동안 메모리 이점이 거의 없이 종료되었습니다. O(1)을 사용한 32비트 접근 방식의 인덱스 액세스. 또한 트리는 저장된 몇 가지 요소에 대해 더 나쁜 런타임을 갖습니다(내 RB 트리 impl로 약 100개 항목 정도를 지불합니다).
• UTF16 서로게이트 페어링
  16비트 형식 배열을 사용하면 코드포인트에 대해 UTF16으로 저하되어야 하며, 이는 런타임 패널티도 도입했습니다(위 주석에 설명됨). BMP보다 높은 코드 포인트는 거의 발생하지 않지만 코드 포인트가 대리 쌍을 형성하는지 여부를 확인하는 것만으로도 ~ 50ms가 추가됩니다.

두 번째 접근 방식의 섹시함은 추가 메모리 절약입니다. 따라서 수정된 BufferLine 구현을 사용하여 놀이터 분기(위 주석 참조)로 테스트했습니다.

예, 파서에서 UTF8 + 형식화된 배열로 변경하기 전에 시작한 위치로 돌아갑니다. 메모리 사용량은 ~ 1.5MB에서 ~ 0.7MB로 떨어졌습니다(87셀 및 1000줄 스크롤백이 있는 데모 앱).

여기서부터는 메모리 절약과 속도의 문제입니다. 우리는 이미 js 배열에서 유형이 지정된 배열로 전환하여 많은 메모리를 절약했으므로(C++ 힙의 경우 ~ 5.6MB에서 ~ 1.5MB로 감소하고 유독한 JS 힙 동작 및 GC를 차단함) 더 빠른 변형으로 여기에 가야 한다고 생각합니다. 메모리 사용이 다시 시급한 문제가 되더라도 여기의 두 번째 접근 방식에서 설명한 대로 더 컴팩트한 버퍼 레이아웃으로 전환할 수 있습니다.

동의합니다. 메모리 소비가 문제가 되지 않는 한 속도를 최적화합시다. 또한 코드를 읽고 유지 관리하기 더 어렵게 만들기 때문에 가능한 한 간접 참조를 피하고 싶습니다. 우리는 이미 많은 사람들(저를 포함하여)이 코드 흐름을 따르기 어렵게 만드는 많은 개념과 조정을 코드베이스에 가지고 있습니다. 이러한 것들을 더 많이 도입하는 것은 항상 정당한 이유가 있어야 합니다. IMO가 또 다른 메가바이트의 메모리를 절약하는 것은 정당화되지 않습니다.

그럼에도 불구하고, 나는 당신의 연습에서 읽고 배우는 것을 정말로 즐기고 있습니다. 아주 자세하게 공유해 주셔서 감사합니다!

@mofux 예
그리고 32비트 레이아웃은 대부분 플랫 메모리(문자 결합에만 간접 참조가 필요함)이기 때문에 더 많은 최적화가 가능합니다(또한 #1811의 일부, 렌더러에 대해 아직 테스트되지 않음).

attr 개체에 대한 간접 지정의 한 가지 큰 이점이 있습니다. 훨씬 더 확장 가능하다는 것입니다. 주석, 글리프 또는 사용자 정의 페인팅 규칙을 추가할 수 있습니다. 링크 정보를 더 깔끔하고 효율적인 방법으로 저장할 수 있습니다. 아마도 셀을 렌더링하는 방법을 알고 사용자 정의 속성을 걸 수 있는 ICellPainter 인터페이스를 정의할 수 있습니다.

한 가지 아이디어는 BufferLine당 두 개의 배열(Uint32Array 및 ICellPainter 배열)을 사용하고 각 셀에 대해 각각 하나의 요소를 사용하는 것입니다. 현재 ICellPainter는 파서 상태의 속성이므로 색상/속성 상태가 변경되지 않는 한 동일한 ICellPainter를 재사용하면 됩니다. 셀에 특수 속성을 추가해야 하는 경우 먼저 ICellPainter를 복제합니다(공유될 수 있는 경우).

가장 일반적인 색상/속성 조합에 대해 ICellPainter를 미리 할당할 수 있습니다. 최소한 기본 색상/속성에 해당하는 고유한 개체가 있어야 합니다.

스타일 변경(예: 기본 전경/배경 색상 변경)은 각 셀을 업데이트할 필요 없이 해당 ICellPainter 인스턴스를 업데이트하기만 하면 구현할 수 있습니다.

가능한 최적화가 있습니다. 예를 들어 단일 너비 및 이중 너비 문자(또는 너비가 0인 문자)에 대해 다른 ICellPainter 인스턴스를 사용합니다. (이는 각 Uint32Array 요소에 2비트를 저장합니다.) Uint32Array에는 11개의 사용 가능한 속성 비트가 있습니다(BMP 문자에 대해 최적화하면 더 많이). 이들은 가장 일반적인 ICellPainter 인스턴스를 인덱싱하는 데 사용할 수 있는 가장 일반적/유용한 색상/속성 조합을 인코딩하는 데 사용할 수 있습니다. 그렇다면 ICellPainter 배열은 느리게 할당될 수 있습니다. 즉, 라인의 일부 셀에 "덜 일반적인" ICellPainter가 필요한 경우에만 가능합니다.

BMP가 아닌 문자에 대한 _combined 배열을 제거하고 ICellPainter에 저장할 수도 있습니다. (이를 위해서는 BMP가 아닌 각 캐릭터에 대해 고유한 ICellPainter가 필요하므로 여기에는 절충점이 있습니다.)

@PerBothner 예 간접 참조는 더 다재다능하므로 드문 추가 기능에 더 적합합니다. 하지만 이드들은 흔하지 않기 때문에 애초에 최적화를 하지 않으려고 합니다.

내가 여러 테스트베드에서 시도한 것에 대한 몇 가지 메모:

• 셀 문자열 내용
  나는 C++에서 와서 C++에서와 같이 문제를 보려고 했기 때문에 내용에 대한 포인터로 시작했습니다. 이것은 단순한 문자열 포인터였지만 대부분의 경우 단일 문자 문자열을 가리킵니다. 낭비야. 따라서 내 첫 번째 최적화는 주소 대신 코드 포인트를 직접 저장하여 문자열 추상화를 제거하는 것이었습니다(JS보다 C/C++에서 훨씬 쉽습니다). 이것은 셀당 12바이트를 절약하면서 읽기/쓰기 액세스를 거의 두 배로 늘렸습니다(8바이트 포인터 + 문자열의 4바이트, 64비트와 32비트 wchar_t). 참고 - 여기서 속도 향상의 절반은 캐시와 관련됩니다(임의의 문자열 위치로 인한 캐시 누락). 이것은 codepoint 에 결합된 비트 세트가 있을 때 인덱싱한 메모리 덩어리인 셀 콘텐츠 결합에 대한 해결 방법으로 명확해졌습니다(valgrind로 테스트한 더 나은 캐시 지역성으로 인해 액세스가 더 빠름). JS로 이월된 속도 향상은 필요한 문자열에서 숫자로의 변환(여전히 더 빠름)으로 인해 그다지 크지 않았지만 메모리 절약은 훨씬 더 컸습니다(JS 유형에 대한 일부 추가 관리 공간으로 인해). 문제는 JS의 큰 반패턴인 명시적 메모리 관리와 결합된 전체 StringStorage 였습니다. 이에 대한 빠른 수정은 정리를 GC에 위임하는 _combined 개체였습니다. 여전히 변경될 수 있으며 btw는 임의의 셀 관련 문자열 내용을 저장하기 위한 것입니다(자소자를 염두에 두고 이 작업을 수행했지만 백엔드에서 지원하지 않으므로 곧 볼 수 없을 것입니다). 따라서 셀 단위로 추가 문자열 내용을 저장하는 곳입니다.
• 속성
  속성을 사용하여 모든 터미널 인스턴스에서 사용된 모든 속성에 대해 전역 AttributeStorage 를 사용하여 "크게 생각"하기 시작했습니다(https://github.com/jerch/xterm.js/tree/AttributeStorage 참조). 메모리 측면에서 이것은 꽤 좋은 결과를 얻었습니다. 주로 ppl이 트루 컬러 지원이 있는 경우에도 작은 속성 세트만 사용하기 때문입니다. 성능은 그다지 좋지 않았습니다. 주로 ref 카운팅(모든 셀이 이 외부 메모리를 두 번 엿봐야 함) 및 attr 일치 때문입니다. 그리고 ref를 JS에 적용하려고 했을 때 잘못된 느낌이 들었습니다. 바로 "STOP" 버튼을 눌렀다는 점입니다. 그 사이에 이미 형식화된 배열로 전환하여 수많은 메모리 및 GC 호출을 절약했으며 따라서 약간 더 비싼 플랫 메모리 레이아웃이 속도 이점을 보상할 수 있습니다.
  내가 테스트한 yday(마지막 코멘트)는 https://github.com/jerch/xterm.js/tree/AttributeStorage 의 트리가 있는 attrs에 대한 라인 수준의 두 번째 유형 배열로 매칭을 위해 (당신의 ICellPainter 아이디어와 거의 비슷합니다) ). 결과가 좋지 않기 때문에 현재로서는 평평한 32비트 레이아웃에 기대고 있습니다.

이제 이 평평한 32비트 레이아웃은 일반적인 것들에 최적화된 것으로 밝혀졌으며 일반적이지 않은 추가 기능은 불가능합니다. 진실. 글쎄, 우리는 여전히 마커를 가지고 있습니다(이들에 익숙하지 않아서 그들이 무엇을 할 수 있는지 지금 당장은 말할 수 없습니다). 그리고 yepp - 버퍼에 여전히 여유 비트가 있습니다(이는 미래의 필요를 위해 좋은 것입니다. 예를 들어 다음과 같이 사용할 수 있습니다. 특별 대우를 위한 깃발 등).

저에게는 attrs 스토리지가 있는 16비트 레이아웃이 그렇게 나쁜 성능을 발휘하는 것이 유감입니다. 메모리 사용량을 절반으로 줄이는 것은 여전히 ​​큰 문제입니다(특히 ppl이 스크롤 라인 >10k를 사용하기 시작할 때). 그러나 런타임 패널티와 코드 복잡성이 더 중요합니다. 상위 mem은 atm imho가 필요합니다.

ICellPainter 아이디어에 대해 자세히 설명해 주시겠습니까? 지금까지 중요한 기능을 놓쳤을 수도 있습니다.

DomTerm에 대한 제 목표는 기존 터미널 에뮬레이터에서 활성화된 것보다 더 풍부한 상호 작용을 활성화하고 장려하는 것이었습니다. 웹 기술을 사용하면 많은 흥미로운 일을 할 수 있으므로 빠른 기존 터미널 에뮬레이터에만 집중하는 것은 부끄러운 일입니다. 특히 xterm.js의 많은 사용 사례(예: IDE용 REPL)는 단순한 텍스트 이상의 이점을 얻을 수 있기 때문에 특히 그렇습니다. Xterm.js는 속도 측면에서 잘 작동하지만(속도에 대해 불평하는 사람이 있습니까?), 기능에서는 그렇지 않습니다(예를 들어 사람들 이 트루컬러 및 내장 그래픽 누락에 대해 불평하고 있습니다). 유연성에 조금 더 집중하고 성능에는 약간 덜 집중하는 것이 가치가 있다고 생각합니다.

_"ICellPainter 아이디어에 대해 자세히 설명해 주시겠습니까?"_

일반적으로 ICellPainter는 Uint32Array에서 가져온 문자 코드/값을 제외한 모든 셀별 데이터를 캡슐화합니다. 이는 "일반" 문자 셀의 경우입니다. 포함된 이미지 및 기타 "상자"의 경우 문자 코드/값이 의미가 없을 수 있습니다.

interface ICellPainter {
    drawOnCanvas(ctx: CanvasRenderingContext2D, code: number, x: number, y: number);
    // transitional - to avoid allocating IGlyphIdentifier we should replace
    //  uses by pair of ICellPainter and code.  Also, a painter may do custom rendering,
    // such that there is no 'code' or IGlyphIdentifier.
    asGlyph(code: number): IGlyphIdentifier;
    width(): number; // in pixels for flexibility?
    height(): number;
    clone(): ICellPainter;
}

셀을 ICellPainter에 매핑하는 것은 다양한 방법으로 수행할 수 있습니다. 분명한 것은 각 BufferLine에 ICellPainter 배열이 있지만 셀당 8바이트 포인터(최소한)가 필요하다는 것입니다. 한 가지 가능성은 _combined 배열을 ICellPainter 배열과 결합하는 것입니다. IS_COMBINED_BIT_MASK가 설정되면 ICellPainter도 결합된 문자열을 포함합니다. 또 다른 가능한 최적화는 Uint32Array에서 사용 가능한 비트를 배열에 대한 인덱스로 사용하는 것입니다. 이렇게 하면 약간의 복잡성과 간접 참조가 추가되지만 공간이 절약됩니다.

나는 우리가 monaco-editor가 하는 방식대로 할 수 있는지 확인하도록 권장하고 싶습니다. 이러한 정보를 버퍼에 저장하는 대신 decorations 를 생성할 수 있습니다. 행 / 열 범위에 대한 장식을 만들고 해당 범위에 고정됩니다.

// decorations are buffer-dependant (we need to know which buffer to decorate)
const decoration = buffer.createDecoration({
  type: 'link',
  data: 'https://www.google.com',
  range: { startRow: 2, startColumn: 5, endRow: 2, endColumn: 25 }
});

나중에 렌더러는 이러한 장식을 선택하여 그릴 수 있습니다.

monaco-editor API가 어떻게 보이는지 보여주는 이 작은 예를 확인하십시오.
https://microsoft.github.io/monaco-editor/playground.html#interacting -with-the-editor-line-and-inline-decorations

터미널 내부에서 그림을 렌더링하는 것과 같은 경우 monaco는 다음 예에서 볼 수 있는 보기 영역 개념을 사용합니다(다른 개념 중에서).
https://microsoft.github.io/monaco-editor/playground.html#interacting -with-the-editor-listening-to-mouse-events

설명과 스케치업을 위해

우리는 결국 미래에 입력 체인 + 버퍼를 웹 작업자로 이동할 계획입니다. 따라서 버퍼는 추상 수준에서 작동하도록 되어 있으며 픽셀 메트릭이나 DOM 노드와 같은 렌더링/표현 관련 항목을 사용할 수 없습니다. DomTerm은 고도로 사용자 정의할 수 있기 때문에 이에 대한 요구 사항이 있다고 생각하지만 향상된 내부 마커 API를 사용하여 이를 수행해야 하며 여기에서 monaco/vscode(thx for th 포인터 @mofux)에서 배울 수 있다고 생각합니다.
저는 코어 버퍼를 비일상적인 것으로 유지하고 싶습니다. 새로운 문제로 가능한 마커 전략에 대해 논의해야 할까요?

16비트 레이아웃 테스트 결과가 여전히 만족스럽지 않습니다. 최종 결정이 아직 시급하지 않기 때문에(3.11 이전에는 이 중 어느 것도 볼 수 없음) 몇 가지 변경 사항으로 계속 테스트할 것입니다(32비트 변형보다 여전히 더 흥미로운 솔루션입니다).

|             uint32_t             |        uint32_t         |        uint32_t         |
|              content             |            FG           |            BG           |
| comb(1) wcwidth(2) codepoint(21) | flags(8) R(8) G(8) B(8) | flags(8) R(8) G(8) B(8) |

나는 또한 시작하기 위해 이것에 가까운 것으로 가야 한다고 생각합니다. 나중에 다른 옵션을 탐색할 수 있지만 이것이 아마도 시작하고 실행하는 것이 가장 쉬울 것입니다. 일반적으로 터미널 세션에는 고유한 속성이 많지 않기 때문에 속성 간접 참조는 확실히 IMO를 약속합니다.

나는 우리가 monaco-editor가 하는 방식대로 할 수 있는지 확인하도록 권장하고 싶습니다. 이러한 정보를 버퍼에 저장하는 대신 장식을 만들 수 있습니다. 행 / 열 범위에 대한 장식을 만들고 해당 범위에 고정됩니다.

이런 일이 일어나는 것을 보고 싶은 곳입니다. 이러한 라인을 따라 내가 가진 한 가지 아이디어는 임베더가 DOM 요소를 범위에 첨부하여 사용자 정의 항목을 그릴 수 있도록 하는 것이었습니다. 이 작업으로 달성하고 싶은 순간에 생각할 수 있는 3가지가 있습니다.

• 이 방법으로 링크에 밑줄을 그립니다.
• * 또는 기타와 같은 행에 마커 허용
• 행이 "깜박이는" 것을 허용하여 어떤 일이 발생했음을 나타냅니다.

이 모든 것은 오버레이로 달성할 수 있으며 이는 매우 접근하기 쉬운 API 유형(DOM 노드 노출)이며 렌더러 유형에 관계없이 작동할 수 있습니다.

임베더가 배경색과 전경색을 그리는 방식을 변경할 수 있도록 하는 사업에 뛰어들고 싶은지 잘 모르겠습니다.

@jerch 나는 이것을 3.11.0 이정표에 넣을 것입니다. 그때에 계획된 JS 배열 구현을 제거할 때 이 문제가 완료된 것으로 간주하기 때문입니다. https://github.com/xtermjs/xterm.js/pull/1796 도 그때 병합될 예정이지만, 이 문제는 항상 버퍼의 메모리 레이아웃을 개선하기 위한 것이었습니다.

또한, 이 나중 논의의 대부분은 https://github.com/xtermjs/xterm.js/issues/484 및 https://github.com/xtermjs/xterm.js/issues/1852 에서 더 나을 것입니다. (장식 문제가 없었기 때문에 생성됨).

@Tyriar Woot - 마침내 닫혔습니다 :sweat_smile:

🎉 🕺 🍾