JavaScript 中的循環展開？

JavaScript 可能會讓人感覺與其運行的硬體非常脫離，但低階思考在有限的情況下仍然有用。

Kafeel Ahmad 最近發表的關於循環優化的文章詳細介紹了許多循環性能改進技術。那篇文章讓我思考了這個主題。

過早的優化

為了解決這個問題，這是一種很少有人在 Web 開發中需要考慮的技術。此外，過早關注優化可能會使程式碼更難編寫、更難維護。了解底層技術可以讓我們深入了解我們的工具和一般工作，即使我們無法直接應用這些知識。

什麼是循環展開？

循環展開基本上複製了循環內的邏輯，因此您可以在每個循環期間執行多個操作。在特定情況下，讓循環中的程式碼更長可以使其更快. 透過有意地以

群組

而不是一對一的方式執行一些操作，電腦也許能夠更有效地運作。 展開範例

讓我們舉一個非常簡單的例子：對數組中的值求和。

雷雷
乍看之下這可能看起來很奇怪。我們正在管理更多變數並執行簡單範例中不會發生的其他操作。這怎麼可能更快？ ！

衡量差異

我對各種資料大小和多次運行以及順序或交錯測試進行了一些比較。 parallelSum 的性能各不相同，但幾乎總是更好，除了非常小的資料大小的一些奇怪結果之外。我使用 RunJS 進行了測試，它是基於 Chrome 的 V8 引擎構建的。

不同的資料大小給出了

非常粗略的

這些結果：

小（

中（10k-100k）：通常快約 20-80%

大（> 1M）：總是快兩倍

然後我創建了一個包含 100 萬筆記錄的 JSPerf 來嘗試跨不同的瀏覽器。自己嘗試吧！

Chrome 運行 parallelSum 的速度是 simpleSum 的兩倍，正如 RunJS 測試所預期的那樣。

Safari 在百分比和每秒操作數方面幾乎與 Chrome 相同。

同一系統上的 Firefox 對於 simpleSum 的表現幾乎相同，但 parallelSum 只快了 15% 左右，而不是快兩倍。

這種變化讓我尋找更多資訊。雖然這還不是明確的，但我發現了 2016 年的 StackOverflow 評論，討論了循環展開的一些 JS 引擎問題。這是對引擎和優化如何以我們意想不到的方式影響程式碼的有趣觀察。

變化

我也嘗試了第三個版本，它在一次操作中添加了兩個值，以查看一個變數和兩個變數之間是否存在明顯差異。

雷雷
簡短回答：不。兩個「並行」版本在彼此報告的誤差範圍內。

那麼它是怎樣工作的呢？

雖然 JavaScript 是單線程的，但是當滿足某些條件時，底層的解釋器、編譯器和硬體可以為我們執行最佳化。

在簡單的範例中，操作需要 i 值來知道要取得哪些數據，並且需要更新 sum 的最新值。由於這兩者在每個循環中都會發生變化，因此電腦必須等待循環完成才能獲取更多資料。雖然對我們來說 i += 1 會做什麼似乎是顯而易見的，但計算機大多理解“值會改變，稍後再檢查”，因此它很難優化。

我們的並行版本為 i 的每個值載入多個資料條目。我們仍然依賴每個循環的總和，但每個週期我們可以載入和處理兩倍的資料。但這並不意味著它的運行速度是原來的兩倍

.

更深層的潛水

為了理解為什麼循環展開有效，我們研究電腦的低階操作。具有超標量架構的處理器可以有多個管道來執行同時操作。它們可以支援無序執行，因此彼此不依賴的操作可以盡快發生。對於某些操作，SIMD 可以同時對多個資料執行一項操作。除此之外，我們開始進入快取、資料取得和分支預測......

但這是一篇 JavaScript 文章！我們不會走得那麼深。如果您想了解更多有關處理器架構的信息，Anandtech 有一些出色的 Deep Dives。

限制和缺点

循环展开并不是魔法。由于程序或数据大小、操作复杂性、计算机体系结构等原因，会出现限制和收益递减。但我们只测试了一两个操作，现代计算机通常支持四个或更多线程。

为了尝试一些更大的增量，我制作了另一个包含 1、2、4 和 10 条记录的 JSPerf，并在运行 macOS 14.5 Sonoma 的 Apple M1 Max MacBook Pro 和运行 Windows 11 的 AMD Ryzen 9 3950X PC 上运行。

一次处理 10 条记录比基本循环快 2.5-3.5 倍，但仅比在 Mac 上处理 4 条记录快 12-15%。在 PC 上，我们仍然看到 1 到 2 条记录之间的性能提升了 2 倍，但 10 条记录仅比 4 条记录快 2%，这对于 16 核处理器来说是我无法预测的。

平台和更新

这些不同的结果提醒我们要小心优化。针对您的计算机进行优化可能会在功能较差或只是不同的硬件上产生更糟糕的体验。当开发人员在快速、强大的机器上工作时，较旧或入门级硬件的性能或功能问题是一个常见问题，这是我在职业生涯中多次面临的任务。

对于某些性能规模，目前推出的 HP 入门级 Chromebook 配备 Intel Celeron N4120 处理器。这大致相当于我的 2013 Core i5-4250U MacBook Air。在综合基准测试中，它的性能仅为 M1 Max 的九分之一。在那台 2013 款 MacBook Air 上，运行最新版本的 Chrome，

4 记录功能 比 10 记录功能快，但仍然只比单记录功能快 60%！ 浏览器和标准也在不断变化。例行的浏览器更新或不同的处理器架构可能会使优化的代码比常规循环慢。当您发现自己进行深度优化时，您可能需要确保您的优化与消费者相关，并且保持相关性

.

这让我想起了 Nicholas Zakas 写的《高性能 JavaScript》一书，我在 2012 年读过这本书。这是一本很棒的书，包含了很多见解。然而，到 2014 年，书中指出的许多重大性能问题已通过浏览器引擎更新得到解决或大幅减少，我们能够将更多精力集中在编写可维护的代码上。 如果您想保持性能优化的领先地位，请为更改和定期验证做好准备。

过去的教训

在研究这个主题时，我遇到了 2000 年的 Linux 内核邮件列表线程，该线程关于删除一些循环展开优化，最终提高了应用程序性能。它包括这个仍然相关的点（强调我的）：

最重要的是，我们对什么快、什么慢的直观假设常常是错误的，

特别是考虑到过去几年 CPU 发生了多大的变化。

– Theodore Ts'o

结论
有时您可能需要从循环中挤出性能，如果您正在处理足够的项目，这可能是您这样做的方法之一。了解此类优化固然很好，但对于大多数工作来说，您并不需要它™。

不过我还是希望你喜欢我的漫谈，也许将来你会记住关于性能优化的考虑因素。

感谢您的阅读！

以上是JavaScript 中的循環展開？的詳細內容。更多資訊請關注PHP中文網其他相關文章！