穿越小说完本,完美世界小说下载

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷解決方案

尤雨溪回應(yīng)：Vite真的比Turbopack慢10倍？

一周前，Vercel 宣布了 Webpack 的基于 Rust 的繼任者 Turbopack。

在公告中，Turbopack 宣稱“比 Vite 快 10 倍”。Vercel 的各種營(yíng)銷材料都重復(fù)宣揚(yáng)這句話，包括推文，博客文章和發(fā)送給 Vercel 用戶的營(yíng)銷電子郵件。

Turbopack 的文檔中還包括了 benchmark 圖，最初表明，使用 TurboPack 的 Next.js 13 可以在 0.01s 中執(zhí)行 React HMR 熱更新，而對(duì)于 Vite 來(lái)說(shuō)需要 0.09s。也有用于冷啟動(dòng)性能的 benchmarks，但是由于沒(méi)有發(fā)現(xiàn)冷啟動(dòng)速度是 Vite 10 倍的比較，因此我們只能假設(shè)“10 倍快”是基于 HMR 的性能。

Vercel 沒(méi)有在營(yíng)銷材料或文檔中使用用于論證這些數(shù)字的 benchmarks 的任何鏈接。因此，我很好奇，并決定使用剛發(fā)布的 Next 13 和 Vite 3.2 的 benchmark 來(lái)驗(yàn)證自己的主張。代碼和方法在此處^[1]開(kāi)源。

我的方法的要點(diǎn)是通過(guò)測(cè)量以下兩個(gè)時(shí)間戳之間的增量來(lái)比較 HMR 性能：

修改源文件的時(shí)間，通過(guò)單獨(dú)的 node.js 進(jìn)程來(lái)觀測(cè)文件更改；
重新渲染更新的 React 組件的時(shí)間，通過(guò)直接在組件的 render 函數(shù)調(diào)用Date.now()來(lái)記錄。請(qǐng)注意，此調(diào)用發(fā)生在組件的虛擬 DOM render 階段，因此不會(huì)受到 React reconciliation 或?qū)嶋H DOM 更新的影響。

benchmark 還測(cè)量了兩種不同情況下的數(shù)字：

“根”案例，該組件會(huì)導(dǎo)入 1,000 個(gè)不同的 child 組件，并且一起渲染。
“葉子”案例，該組件是由根導(dǎo)入，但自身沒(méi)有子組件。

差別

在聊數(shù)字之前，有幾個(gè)額外的差異值得一提：

Next 是否使用 React Server Component（RSC）。
Vite 是否使用 SWC 來(lái)替代 Babel 進(jìn)行 React 轉(zhuǎn)義。

React Server Components

Next 13 引入了一個(gè)主要的架構(gòu)轉(zhuǎn)變，因?yàn)楝F(xiàn)在組件默認(rèn)為服務(wù)器組件，除非用戶使用“use-client”指令明確選擇客戶端模式。不僅是默認(rèn)設(shè)置，Next 文檔還建議用戶盡可能保持服務(wù)器組件模式，以提高終端用戶的性能。

我的初始 benchmark 測(cè)試測(cè)了 Next 13 在服務(wù)器模式下的根組件和葉組件的 HMR 性能。結(jié)果表明，在這兩種情況下，Next 13 的速度實(shí)際上都較慢，并且葉組件的差異顯著。

Round 1 snapshot (Next w/ RSC, Vite w/ Babel)^[2]

當(dāng)我在 Twitter 上發(fā)布這些數(shù)字時(shí)，很快就有人指出，我應(yīng)該在沒(méi)有 RSC 的情況下對(duì) Next 組件進(jìn)行 benchmark 測(cè)試，以使其相等。所以我在 Next 根組件中添加了“useclient”指令，以選擇進(jìn)入客戶端模式。事實(shí)上，在客戶端模式下，Next HMR 顯著提高，比 Vite 快 2 倍：

Round 2 snapshot (Next w/o RSC, Vite w/ Babel)^[3]

SWC vs. Babel Transforms

我們的目標(biāo)是使 benchmark 只關(guān)注 HMR 性能差異。為了確保我們確實(shí)在比較同一個(gè)東西，我們還應(yīng)該消除另一個(gè)變量：Vite 的默認(rèn) React preset 使用 Babel 來(lái)轉(zhuǎn)換 React HMR 和 JSX。

React HMR 和 JSX 轉(zhuǎn)換不是與構(gòu)建工具耦合的特性?？梢酝ㄟ^(guò) Babel（基于 js）或 SWC（基于 rust）完成。Esbuild 也可以轉(zhuǎn)換 JSX，但缺少對(duì) HMR 的支持。

SWC 明顯快于 Babel（單線程下 20 倍，多核心下 70 倍）。Vite 目前默認(rèn)為 Babel 的原因是在安裝大小和實(shí)用性之間進(jìn)行權(quán)衡。SWC 的安裝容量相當(dāng)大（node_modules 中占用 58MB，而 Vite 本身才 19MB），許多用戶仍然依賴 Babel 進(jìn)行其他轉(zhuǎn)換，因此 Babel pass 對(duì)他們來(lái)說(shuō)是不可避免的。當(dāng)然，這在未來(lái)可能會(huì)改變。

Vite core 不依賴 Babel。只需要用 vite-plugin-swc-react-refresh^[4] 來(lái)替換默認(rèn)的 React 插件即可。切換后，我們看到了根案例中 Vite 的顯著改進(jìn)，超過(guò)了 Next：

有趣的是，這里的成長(zhǎng)曲線顯示，Next/turbo 在根情況下比葉情況下慢 4 倍，而 Vite 只慢 2.4 倍。這意味著 Vite HMR 在更大型的組件中表現(xiàn)更好。

此外，切換到 SWC 也應(yīng)改善 Vercel benchmark 測(cè)試中 Vite 的冷啟動(dòng)指標(biāo)。

在不同的硬件上的性能

因?yàn)檫@是一個(gè)涉及 Node.js 和和原生 Rust 部分的復(fù)合測(cè)試，在不同的硬件上會(huì)有非凡的差異。我發(fā)布的結(jié)果是在我的 M1 MacBook Pro 上收集的。其他用戶在不同的硬件上運(yùn)行了相同的 benchmark 測(cè)試，并報(bào)告了不同的結(jié)果。

在某些情況下，根案例下的 Vite 更快。

而在另外一些情況下，兩種情況下 Vite 都明顯更快。

Vercel 的澄清

在我發(fā)布了我的 benchmark 之后，Vercel 發(fā)布了一篇博文^[5]，澄清了他們的 benchmark 方法，并將其 benchmark 提供給公眾驗(yàn)證。雖然這可能是第一天就做的事兒，但這絕對(duì)是朝著正確方向邁出的一步。

讀完帖子和 benchmark 代碼后，這里有幾個(gè)關(guān)鍵要點(diǎn)：

Vite 實(shí)現(xiàn)仍然使用默認(rèn)的基于 Babel 的 React 插件。
1k 組件的案例下有數(shù)字的四舍五入問(wèn)題，Turbopack 的 15ms 被舍入城 0.01s，Vite 的 87ms 被舍入城 0.09s。這把本來(lái)接近 6 倍的差距擴(kuò)大到了 10 倍。
Vercel 的 benchmark 使用更新模塊的“瀏覽器 eval 時(shí)間”作為結(jié)束時(shí)間戳，而不是 React 組件重新渲染時(shí)間。
該帖子包括一張圖表，顯示當(dāng)模塊總數(shù)超過(guò) 30k 時(shí)，Turbopack 可以比 Vite 快 10 倍。

總結(jié)下來(lái)，“比 Vite 快 10 倍”必須在以下條件下才成立：

Vite 未使用相同的 SWC 轉(zhuǎn)換。
該應(yīng)用程序包含超過(guò)30k個(gè)模塊
Benchmark 只測(cè)量熱更新模塊被評(píng)估的時(shí)間，而不是實(shí)際應(yīng)用更改的時(shí)間。

什么是“公平”比較？

由于 Vercel 的 benchmark 測(cè)試測(cè)量“模塊評(píng)估時(shí)間”，以排除 React 的 HMR 運(yùn)行時(shí)引起的差異，我們可以假設(shè) benchmark 測(cè)試的目標(biāo)是對(duì) Vite 和 Turbopack 固有的 HMR 機(jī)制進(jìn)行公正的比較。

不幸的是，在這個(gè)前提下，Vite 仍然在 benchmark 測(cè)試中使用 Babel，這并不平等，這讓 10 倍速度的聲明無(wú)效了。在使用 SWC 轉(zhuǎn)換的 Vite 來(lái)矯正數(shù)字之前，應(yīng)將其視為不準(zhǔn)確的測(cè)試。

此外，我相信大多數(shù)人都會(huì)同意：

對(duì)于絕大多數(shù)用戶來(lái)說(shuō)，30k 模塊數(shù)量是一個(gè)極不可能的場(chǎng)景。隨著 Vite 使用 SWC，達(dá)到 10 倍要求所需的模塊數(shù)量可能會(huì)變得更加不切實(shí)際。雖然這在理論上是可能的，但用它來(lái)證明 Vercel 一直營(yíng)銷的成績(jī)，是很虛偽的。
用戶更關(guān)心端到端的 HMR 性能，即從保存到看到反映的更改的時(shí)間，而不是理論上的“模塊評(píng)估”時(shí)間。當(dāng)看到“更新速度快 10 倍”時(shí)，一般用戶會(huì)考慮前者而不是后者。Vercel 在其營(yíng)銷中圖方便省略了這一警告。實(shí)際上，Next 中服務(wù)器組件的端到端 HMR（默認(rèn)值）比 Vite 中的慢。

作為 Vite 的作者，我很高興看到像 Vercel 這樣資金雄厚的公司在改進(jìn)前端工具方面進(jìn)行了大量投資。如果適用，我們甚至可以在未來(lái)在 Vite 中利用 Turbopack。我相信 OSS 領(lǐng)域的健康競(jìng)爭(zhēng)最終會(huì)讓所有開(kāi)發(fā)者受益。

然而，我也認(rèn)為開(kāi)放源碼軟件的競(jìng)爭(zhēng)應(yīng)該建立在公開(kāi)溝通、公平比較和相互尊重的基礎(chǔ)上。令人失望和擔(dān)憂的是，看到激進(jìn)的營(yíng)銷使用了精心挑選的、未經(jīng)同行評(píng)審的、邊緣誤導(dǎo)性的數(shù)字，這些數(shù)字通常只在商業(yè)競(jìng)爭(zhēng)中出現(xiàn)。作為一家建立在 OSS 成功之上的公司，我相信 Vercel 可以做得更好。

文章題目：尤雨溪回應(yīng)：Vite真的比Turbopack慢10倍？
新聞來(lái)源：http://m.fisionsoft.com.cn/article/dhgpgop.html