功能價格文件部落格
取得 mote
← 部落格
工程·2026年8月27日·閱讀時間 5 分鐘

不只說「輕巧」,而是公開數據的理由

說「輕量」沒有任何可供驗證之處。mote 為自己定下八個用數字說話的指標,並一併公開測量方法、條件與原始資料。

m
mote
在同一台機器上使用同一支腳本測量四款應用程式的記憶體、輸入文字時的 CPU 使用率與程序數。最下方另有註記,說明閒置 CPU 並非一項優勢。
在同一台機器上使用同一支腳本測量四款應用程式的記憶體、輸入文字時的 CPU 使用率與程序數。最下方另有註記,說明閒置 CPU 並非一項優勢。

Markdown 編輯器經常被這樣介紹。

快速。輕量。流暢。

但數字若缺少條件,就和形容詞沒有兩樣。閒置 CPU 是何時測量、測量了多久。啟動時間是從哪裡計算到哪裡。因為條件不同的數字無法互相比較。

因此,我們將 mote 公開的效能指標定為 8 項。每項指標都記錄了測量方法與條件、排除項目、比較規則、注意事項及預算,也逐一連結了測量腳本。

文件、結果與程式碼全都使用相同的名稱,讓人能立即追查數字的來源。

數字必須附帶條件

mote 遵守四項原則。

每個測量值都會連同數值與單位、統計資料、樣本數及原始樣本一起儲存。缺少單位的結果會在檢查階段遭到拒絕。

沒有測量的數值就不填寫。若無法測量,便附上原因並留白,不以估算值填補。

只在同一台機器與同一個工作階段內進行比較。不會將不同日期、不同裝置得出的數字並列比較。

測量條件也會與數字一併公開。尤其是螢幕更新率與 CPU governor,必定會加以記錄。若這些條件不同,就無法正確比較延遲時間與啟動時間。

執行一次閘門後輸出的一行結果 — exec→視窗 246 ms、第一幀 275 ms、閒置幀數 0、閒置 CPU 0.10 %、PSS 121 MB、執行緒 12。下方的灰色一行是記錄產生這些數字之條件的位置
執行一次閘門後輸出的一行結果 — exec→視窗 246 ms、第一幀 275 ms、閒置幀數 0、閒置 CPU 0.10 %、PSS 121 MB、執行緒 12。下方的灰色一行是記錄產生這些數字之條件的位置

我們並未另創新的測量方法。

從按鍵輸入到畫面發生變化的延遲,完全採用 Pavel Fatin 的 Typometer 所使用的方法。從應用程式外部輸入按鍵,再確認像素何時改變。啟動時間則比照 VS Code 分成多個階段,並區分冷啟動與暖啟動。

延遲必須端到端測量,而非只在框架內測量;這項原則取自 Dan Luu 的文章。

我們親自在相同條件下進行比較

對於競爭應用程式的效能,我們沒有引用其他地方的數字,而是親自在同一台筆記型電腦上測量。

我們開啟相同的 100KB 文件,以同一支腳本對每款應用程式各執行 7 次。全部使用行內編輯畫面,游標位置也設為相同。

整個程序的記憶體使用量如下。

  • mote: 78MB
  • Typora: 453MB
  • Obsidian: 361MB
  • MarkText: 416MB

輸入文字時,以單一核心為基準的 CPU 使用率分別為 10.9%、103%、152%、136%。程序數則分別為 1 個、8 個、7 個、6 個。

mote 的記憶體使用量少了 4.6 倍至 5.8 倍。輸入文字時使用的 CPU 則少了 9.4 倍至 14 倍。

記憶體並非以 RSS,而是以 PSS 計算。RSS 可能會重複計入多個程序共用的記憶體。PSS 則會依程序數分攤計算共用記憶體,也與系統監視器所採用的方式相同。

不利的數字也原樣保留

僅開啟應用程式而不進行操作時,CPU 使用率分別為 mote 0.0%、Typora 0.1%、Obsidian 0.8%、MarkText 0.6%。

Typora 在閒置狀態下也幾乎不使用 CPU。因此,「開著時什麼也不做」這一點不能被當成優於 Typora 的優勢。

Web shell 使用了 3.6%,反而比 Typora 更差。

移除應用程式內部的循環計時器依然很重要。但必須遵守的原則與競爭優勢是兩回事。

閒置幀數沒有與競爭應用程式比較。mote 的目標是在 10 秒內保持 0 幀,但其他應用程式並沒有能以相同方式確認的幀數計數器。

因此,競爭應用程式的欄位保持空白。空白並不代表 0。

無法比較,就不比較

我們也會確認檔案在開啟後未經修改便儲存時,原始內容是否維持不變。

mote 會檢查 652 個 CommonMark 範例。也會開啟儲存庫中的所有文件並重新儲存,再確認是否逐位元組完全相同。只要有一處不同,就會被視為資料遺失錯誤,而非效能問題。

我們沒有填寫競爭應用程式的結果,因為很難在相同條件下自動化其儲存流程。

測量前也會確認機器的狀態。如果編譯正在執行,就不會開始測量。瀏覽器則只有在實際大量使用 CPU 時才會阻止測量。負載平均值、CPU 閒置率、判斷標準,以及測量當時的數值,全都會保留在結果中。

這項規則是在經歷失敗後才建立的。

開著大量使用 CPU 的瀏覽器測量啟動時間時,看起來就像效能變差了。讓先前的 commit 與目前的 commit 在相同負載下交替接受測量後,才發現原因不是程式碼退步,而是機器負載。

從那之後,我們不再只看單一絕對值來判斷啟動時間。

超出預算就無法合併

效能預算不只是寫在文件裡的目標,而是建置要通過就必須遵守的標準。

標準分為 hardreport

hard 是已在決策文件中確定數值的項目。只要有一項超出標準,檢查就會失敗,也沒有另外核准例外的機制。

report 是目前依據仍不足,或容易受到平台限制影響的項目。其數值會被記錄,但不會阻止建置。

如果用缺乏依據的數字阻止建置,人們就會開始逃避測量本身。因此,只有明確的標準才會用作閘門。

預算表中的六項 hard 項目 — 閒置幀數 0 / 10 s、閒置 CPU 0.3 %、從外部測得的按鍵→像素 p95 33.4 ms、從內部測得的按鍵處理 p95 4 ms、冷啟動中由我們造成的部分 10 ms、記憶體中由我們占用的部分 8 MB。右側欄位是記錄各項指標測量方法的位置
預算表中的六項 hard 項目 — 閒置幀數 0 / 10 s、閒置 CPU 0.3 %、從外部測得的按鍵→像素 p95 33.4 ms、從內部測得的按鍵處理 p95 4 ms、冷啟動中由我們造成的部分 10 ms、記憶體中由我們占用的部分 8 MB。右側欄位是記錄各項指標測量方法的位置

測量腳本、原始 CSV 與結果 JSON 都會一併保存在儲存庫中。只要在相同條件下執行相同腳本,就能重新產生表格。我們也正在準備將測量工具與測試文件以公開基準測試儲存庫的形式釋出。

只挑好看的數字並不叫公開。

把測量了什麼、如何測量、當時有哪些條件,以及哪些項目無法測量都一起展示出來。這就是 mote 公開數字的方式。

← 較舊讓程式閒置開啟時不占用 CPU 的方法較新 →以檔案為真相來源,只儲存我實際輸入的位元組
透過 RSS 持續關注。
只留下文字。
繁體中文
© 2026 mote