從 Application Timing 到 Runtime Attribution，確認改善到底發生在哪一層？

昨天完成 composable-chaos 的 Vue 3.5.40 Baseline 後，我們確認 Composable Chain 越深，Runtime Work 越多。

今天換成 Vue 3.6.0-rc.2，探討 同一個 Composable Scenario，Vue 3.6 有沒有降低這些 Cost？

這次仍然分兩層觀測：

• Layer A：Scenario Instrumentation

  Composable、Computed、Watch、Render，以及 Application Timing。

• Layer B：Chrome CDP Trace

  Scripting、Application CPU、Vue Runtime CPU，以及 Runtime Attribution。

這個拆分很重要，因為 Application Timing 變快，只能證明這段程式執行時間下降，還需要繼續追查改善發生在哪一層。

先固定實驗條件

Validation 沿用昨天建立的 composable-chaos，只更換 Vue 版本。

因此這次比較的主要變因就是 Vue Version。

Reactive Graph：工作量沒有改變

先看 Depth 20 的 Runtime Counters：

四個 Depth 的結果也維持一致。

Depth 20
  ↓
19 Computed
  ↓
1,919 Computed Execute
  ↓
相同 Watch / watchEffect Trigger
  ↓
相同 Render Count

這表示 Vue 3.6 沒有改變這個 Scenario 的 Reactive Graph，也沒有讓這些操作從執行路徑中消失，但 相同工作量，不代表執行成本相同，所以接下來才是關鍵。

Application Timing：Vue 3.6 看起來變快了

把 Baseline 與 Validation 放在一起，Depth 10、20 的差異開始明顯：

Depth 20 Update 從 4.986 ms → 3.930 ms，從 chart 看更明顯 Depth 越深，Scripting Cost 在兩個 Vue 版本都單調增加。

• Depth 越深，Work 越多
• Vue 3.6 的改善主要集中在 Depth 20 Update

Scripting 也下降了

因此我們再用 CDP Trace 看同一組 Depth 20 Update。

這裡的訊號更強，5 次 paired trials 全部呈現相同方向：

Application Duration   ↓
Scripting              ↓

因此可以合理確認 Depth 20 Update 存在可重現的 JS-level improvement。

但是仍然不能直接等同於 Vue Runtime improvement，因為 Scripting 裡面還包含 Application JavaScript 與 Vue Runtime。

Runtime Attribution：結果開始反轉

再往下一層看 CPU attribution：

這裡出現一個值得注意的結果：

Scripting               −25.6%
Application CPU         +41.3%
Vue Runtime CPU         +67.1%

目前的 Evidence 不支持「Vue 3.6 讓 Composable Runtime 變快 25.6%」這個說法，而且 Runtime Attribution 本身還存在限制：

• attribution confidence：low
• leaf-only sampling
• 部分 trial 出現 0-sample

所以這組資料適合用來 限制結論範圍，不適合拿來宣稱 Framework Runtime 已經取得明確改善。

目前能證明什麼？

把三層 Evidence 放在一起：

得到的結論是：在 composable-chaos 中，Vue 3.6.0-rc.2 的 Depth 20 Update 出現可重現的 Application 與 JS-level improvement；但目前的 Runtime Attribution Evidence 不足以證明改善來自 Vue Framework Runtime。

這也解釋了為什麼同一個 Validation Lab 要同時保留 Application Timing 與 CDP Trace。

如果只看 performance.now() −21.2%，很容易把結果直接歸因給 Vue。

所以再往下拆：

Scripting
├─ Application JS
└─ Vue Runtime

才發現目前真正能確認的只有 JS-level Cost 下降。

不同 Scenario，驗證的 Cost 也不同

這次結果也可以和前面的實驗放在一起看：

例如 VDOM Stress 的大量 Node 測試中，Cost 很大一部分落在 Browser Rendering，尤其是 Layout。

Composable Chaos 則把觀察點拉回：

State
 ↓
Composable
 ↓
Computed
 ↓
Watch
 ↓
Component Update

所以 Validation Lab 真正要回答的問題，始終是 Cost 到底發生在哪一層？

小結

這次驗證可以先記住三件事：

1. Reactive Graph 沒變：Computed、Watch、Render 等工作量都一樣。
2. Depth 20 Update 變快了：Application Timing −21.2%，Scripting −25.6%，兩邊測到的結果方向一致。
3. 還不能說是 Vue Runtime 變快：Runtime Attribution 的可信度不足，這次的資料還無法確認 −25.6% 到底有多少來自 Vue Runtime。

簡單講：

Reactive Work      → 沒變
JS Cost            → 下降
Vue Runtime Cost   → 還不能確認

所以這次可以確認 Vue 3.6 在這個 Scenario 的 Depth 20 Update 確實跑得比較快，但目前還不能把這個改善直接算在 Vue Runtime 身上。

Report

• Composable Chaos: Vue 3.6.0-rc.2 Validation