GC 吃 74% CPU,這才是 Liquid 快 53% 的原因。Shopify CEO 用 autoresearch 跑 120 次實驗,每次先過 974 個測試再 benchmark,方法可複製,前提是先有測試套件。
⭐ 文章深度讀:autoresearch 拆解:120 次實驗的流程,以及複製的前提條件
→ https://heymaibao.com/liquid-53-percent-faster-gc-insight/
⚡ 章節重點
老系統為何還能快 53%? 00:00
GC 才是速度殺手,74% CPU 去哪了 01:23
autoresearch:AI 自動化研究員怎麼跑實驗 02:57
失敗清單為何比成功清單更重要 04:26
這件事對你有什麼意義 05:22
📝 懶人包
∙ GC (垃圾回收機制) 佔了 74% 的總 CPU 時間,代表每減少一個物件建立,就等於把大量原本浪費在 GC 的 CPU 時間還給真正的運算。這解釋了為什麼 parse 時間能砍 61%、render 只砍 20%,兩者的 allocation 密度本來就不同。
∙ Shopify CEO Tobias Lütke 用 autoresearch (自動化研究迴路) 跑了約 120 次實驗,能這樣做的前提是 974 個 unit tests (單元測試),每次改動都先過測試才做 benchmark (效能基準測試),沒過測試直接捨棄,速度不能拿正確性換。
∙ PR 裡「沒有用的優化」清單比優化清單更重要:split-based tokenizer 理論上快 2.5 倍卻語法邊界不符、String#match 提取名稱反而多建立 5,000 個物件、TruthyCondition 子類別讓 YJIT (Ruby 即時編譯器) 的多型代價超過省下的 allocation。這張清單說明不是亂試,每個決策都有客觀依據。
∙ 我的觀察:autoresearch 模式真正的門檻不是 AI 有多強,而是你是否有夠強健的測試套件。沒有測試套件,「保留/捨棄迴路」就沒有可信賴的判斷基準。Liquid 能做這件事,是因為它先有 974 個測試,不是因為 AI 夠厲害。
📚 參考資料
Shopify/liquid: Performance: 53% faster parse+render, 61% fewer allocations
→ https://github.com/Shopify/liquid/pull/2056
Simon Willison 的觀察
→ https://simonwillison.net/2026/Mar/13/liquid/