문서가 길어져도 타이핑이 느려지지 않는 이유

짧은 메모는 어떤 에디터로 써도 빨라요. 차이는 문서가 길어질 때 드러나요.

키를 누를 때마다 문서 전체를 다시 읽고 화면을 새로 배치한다면, 문서가 길어질수록 입력도 느려져요. 열 줄짜리 메모에서는 괜찮던 에디터가 이천 줄짜리 설계 문서에서 답답해지는 이유예요.

mote는 이 문제를 나중에 고칠 성능 이슈로 보지 않았어요. 처음부터 지켜야 할 설계 원칙으로 정했어요.

편집할 때는 바뀐 범위만 다시 읽고 배치한다. 문서 전체를 다시 읽는 건 파일을 열 때뿐이다.

바뀐 곳만 다시 읽어요

마크다운에서는 앞줄이 뒷줄의 의미를 바꿀 수 있어요. 문서 위에서 코드 블록을 열면 아래 내용이 모두 코드가 될 수 있고, 같은 문장도 목록이나 인용문 안에서는 다르게 읽혀요.

그래서 mote는 앞의 영향이 확실히 끝나는 ‘안전 지점’을 기억해 둬요. 편집이 생기면 가까운 안전 지점에서 읽기 시작해, 내용이 다시 안정되는 순간 멈춰요.

그 뒤의 블록은 다시 읽지 않아요. 줄이 늘거나 줄었다면 위치만 옮겨요. 비용이 문서 전체가 아니라 실제로 바뀐 범위를 따라가게 만든 거예요.

파서는 CommonMark의 줄 단위 알고리즘을 따르고, 스펙 테스트 652개를 모두 통과해요. 하지만 증분 처리는 조용히 틀리기 쉬워요. 그래서 무작위 문서에 무작위 편집을 3,600번 적용한 뒤, 매번 문서 전체를 다시 읽은 결과와 비교해요.

이 검사는 실제 버그도 찾아냈어요. 안전 지점과 편집한 줄이 정확히 겹치는 경우였어요.

성능 원칙은 검사로 지켜요

목표는 키를 누른 뒤 코어 처리가 끝날 때까지 p95 4ms예요. 이 시간을 넘기면 개선 과제가 아니라 버그로 다뤄요.

규칙을 문서에만 적어 두지도 않았어요. 자동 검사가 전체 재파싱이 파일을 열 때만 쓰이는지 확인해요. 유휴 상태에서 반복되는 타이머나 프레임 작업도 막아요.

성능도 사람이 눈으로 판단하지 않아요. 하네스가 실제 화면에 키를 입력하고 처리 시간의 분포를 측정해요. 평균이나 중앙값 대신 p95를 봐요. 사용자를 답답하게 만드는 건 평소의 속도보다 가끔 나타나는 긴 지연이기 때문이에요.

측정에는 언제나 같은 고정 문서를 써요.

화면도 필요한 만큼만 바꿔요

파서만 증분으로 바꿔서는 충분하지 않았어요.

코드 블록의 문법 강조는 편집할 때마다 모든 블록을 다시 처리하고 있었어요. 편집 크기와 상관없이 문서가 길수록 느려지는 마지막 작업이었죠.

지금은 수정하지 않은 블록의 문법 강조를 그대로 재사용해요. 편집 뒤의 블록은 줄 수가 달라진 만큼 위치만 옮겨요.

화면 밖의 블록은 레이아웃하지 않아요. 다시 읽는 범위와 다시 그리는 범위를 모두 줄여야 긴 문서에서도 속도를 지킬 수 있기 때문이에요.

예외도 있어요

문서 전체를 다시 처리해야 할 때가 있어요.

파일을 열거나 줄바꿈 형식이 바뀔 때예요. 링크 참조 정의를 고치면 문서 어디에 있는 링크든 달라질 수 있어서, 화면 갱신 범위도 문서 전체로 넓혀요.

코어가 빨라도 화면에는 다음 프레임을 기다리는 시간이 필요해요. 60Hz 화면이라면 프레임 간격 자체가 한계가 돼요. 그래서 코어 처리 시간과 실제 화면에 나타날 때까지의 시간을 따로 재고, 두 숫자를 같은 축에 올려놓지 않아요. 표지의 두 줄이 다른 이유예요.

빠른 에디터는 모든 일을 빨리 하는 에디터가 아니에요.

하지 않아도 될 일을 하지 않는 에디터예요.