文件再長，打字也不會變慢的原因

簡短筆記用任何編輯器來寫都很快。差異會在文件變長時顯現。

如果每次按鍵時都重新讀取整份文件並重新配置畫面，那麼文件越長，輸入也會越慢。這就是為什麼在只有十行的筆記中還很順暢的編輯器，到了兩千行的設計文件裡就會讓人感到卡頓。

mote 沒有把這個問題視為日後再修正的效能問題。它從一開始就被定為必須遵守的設計原則。

編輯時，只重新讀取並配置變更的範圍。只有開啟檔案時才重新讀取整份文件。

只重新讀取變更之處

在 Markdown 中，前面的行可能會改變後面各行的意義。如果在文件前段開啟程式碼區塊，下面的內容可能全都變成程式碼，而同一句話在清單或引言中也會有不同的解讀。

因此，mote 會記住前方影響確定結束的「安全點」。發生編輯時，便從附近的安全點開始讀取，並在內容重新穩定的那一刻停止。

之後的區塊不會重新讀取。如果行數增加或減少，就只移動位置。這讓成本不再取決於整份文件，而是跟著實際變更的範圍走。

解析器遵循 CommonMark 的逐行演算法，並通過全部 652 項規格測試。但增量處理很容易在不知不覺中出錯。因此，我們會對隨機文件套用 3,600 次隨機編輯，並在每次編輯後，與重新讀取整份文件的結果進行比較。

這項檢查也找出了實際的錯誤。那是安全點與編輯行恰好重疊的情況。

用檢查來守住效能原則

目標是從按下按鍵到核心處理完成，p95 為 4ms。超過這個時間時，不會把它當成改善事項，而是視為錯誤處理。

規則也不只是寫在文件裡。自動檢查會確認完整重新解析只在開啟檔案時使用，也會阻止閒置狀態下反覆執行的計時器或影格工作。

效能也不由人用肉眼判斷。測試工具會在實際畫面中輸入按鍵，並測量處理時間的分布。我們看的是 p95，而不是平均值或中位數。因為讓使用者感到卡頓的，與其說是平常的速度，不如說是偶爾出現的長時間延遲。

測量時永遠使用同一份固定文件。

畫面也只變更必要的部分

只把解析器改成增量處理還不夠。

程式碼區塊的語法突顯原本會在每次編輯時重新處理所有區塊。這是最後一項不論編輯範圍大小，都會隨文件變長而變慢的工作。

現在，未修改區塊的語法突顯會直接沿用。編輯位置之後的區塊，只會依行數的變化移動位置。

畫面外的區塊不會進行版面配置。因為必須同時縮小重新讀取與重新繪製的範圍，才能在長文件中維持速度。

也有例外

有些時候必須重新處理整份文件。

例如開啟檔案或換行格式改變時。修改連結參照定義後，文件中任何位置的連結都可能改變，因此畫面更新範圍也會擴大到整份文件。

即使核心很快，畫面仍需要時間等待下一個影格。在 60Hz 畫面上，影格間隔本身就會成為極限。因此，核心處理時間與實際顯示在畫面上所需的時間會分開測量，不會把兩個數字放在同一條軸線上。這就是封面上兩條線不同的原因。

快速的編輯器，並不是把所有事情都做得很快的編輯器。

而是不做那些不必做的事情的編輯器。