本文翻譯自 Chrome DevTools: Show native functions in JS Profile，中文版首發在我的知乎專欄 V8 源碼及周邊。

在 Chrome DevTools 中可以使用 profiler 查看原生函數的執行性能：

原生函數（native function）是 JavaScript 語言的一部分，這些函數有別于開發者編寫的自定義函數。當我們在 profiler 中查看代碼的調用棧時，這些函數是被過濾掉的。我們在 profiler 中看到的只有自己寫的代碼。

當我們捕獲調用棧時，Chrome 并不會捕獲 C++ 寫的函數。不過，在 V8 引擎中很多 javascript 原生函數都是使用 javascript 語言編寫的。

V8 使用 JavaScript 本身實現了 JavaScript 語言的大部分內置對象和函數。 例如，promise 功能就是通過 JavaScript 編寫的。我們把這樣的內置函數稱為自主托管（self-hosted）。

如果我們開啟 “Show native functions” 設置，Chrome 將會在 profiler 中顯示這些函數。

Chrome 分析器是如何工作的

為了找到那些耗時最多的代碼，Chrome 分析器每 100μs 捕獲一個堆棧跟蹤。

這意味著，如果一個函數只需要 50μs 的執行時間，就可能不會在分析器中顯示出來！

當你分析幾毫秒以上的時間時，可以準確了解應用程序在何時花費最多的時間。 但是，當你放大 profiler 面板想看更精準的時間時，信息會變得不太準確。

分析器也會不一致。 每次運行時，會產生一個稍微不同的結果。 有時可能會記錄非常短的函數調用，而在其他時間再次運行這些函數調用信息可能會丟失。

通過這篇博客文章我將為大家演示如何捕獲并分析原生函數的性能。當你自己運行代碼時，結果可能會有所不同。

Array.join

首先，我們運行如下代碼：

var arr = [] for (var i=0; i<1000; i++){arr.push(i) } console.profile("Array.join") arr.join(",") console.profileEnd("Array.join")復制代碼

選擇 profiler 的 “Chart” 視圖：

第一次分析時，我們不選中 “Show native functions”：

我們再次運行時，把 “Show native functions” 啟用：

當我們把鼠標指向函數時，會看到更加詳細的信息：

如上信息中，chrome devtools 展示了原生函數的行號，你可以在 Chrome code search中找到這個文件 “array.js”。行號信息可能不同，因為 V8 源碼的最新版本和 Chrome 使用的 V8 版本可能不一樣。

你可以看到 ArrayJoin 函數在內部調用了 InnerArrayJoin：

function ArrayJoin(separator) {CHECK_OBJECT_COERCIBLE(this, "Array.prototype.join");var array = TO_OBJECT(this);var length = TO_LENGTH(array.length);return InnerArrayJoin(separator, array, length); }復制代碼

InnerArrayJoin 在內部調用了 DoJoin。

DoJoin 調用了 %StringBuilderJoin。

%StringBuilderJoin 是使用 C++ 實現的。

稀疏數組

我們有點偏離主題，但是我認為 V8 處理稀疏數組（new Array(n)）是非常有趣的。

為什么這很有用呢？

下面的代碼是如何運行的？

arr = new Array(10000000) for (var i=0; i<10000; i++){arr.push(i) } console.profile("arr + arr") arr + arrconsole.profileEnd("arr + arr")復制代碼

您通常不會在兩個數組上執行加操作。但是由于某種原因，我最近看過的一些代碼就是這樣做的。

當不是用查看原生函數時，我們看到了一個匿名函數的調用。

當我們開啟了查看原生函數功能時，Chrome 調用了 array 的 toString 方法，然后調用了 join 方法。

Error().stack

我們來看一個不同的例子。在 JavaScript 中，您可以使用 Error().stack 獲取當前正在運行的函數的堆棧跟蹤（stack trace）。

當我們運行該代碼時，一共做了兩件事： 首先我們創建一個新的 Error 對象，然后訪問它的 stack 屬性。

獲取堆棧跟蹤的字符串描述信息時，耗費了大量的時間。

我能夠通過獲取一個 Error 對象來加快我正在處理的代碼：只有當我需要顯示堆棧跟蹤時，才解析其 stack 屬性。

不準確的地方

在我的文章的開頭章節，我提到了非常小的時間間隔可能造成結果的不準確。為了說明這一點，我在另一臺不同配置的電腦上運行了 Error().stack 的代碼段。

我們看到了 FormatErrorString 函數，而在之前的分析中，這個函數并沒有顯示出來。

（這次的總執行時間是 ~1ms，這意味著 Chrome 需要 10 個調用堆棧的樣本。上面的例子花了 ~10ms，因為我在循環中調用了 10 次 Error().stack。）

相關閱讀

• 移動 Web 滾動性能優化：Passive Event Listeners
• 使用 D8 分析 javascript 如何被 V8 引擎優化的
• 開啟 V8 對象屬性的“fast”模式

如果對 V8 引擎干興趣，我在 4月15（星期六）晚 8 點和大家一起聊聊 V8 引擎：前端程序員應該懂點 V8 知識 - SegmentFault 講堂。

總結

以上是生活随笔為你收集整理的Chrome DevTools：在 Profile 性能分析中显示原生 javascript 函数的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。