Liquid 模板引擎加速 53%，但這個 GC 洞察比數字更值得學

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/