首頁 >web前端 >js教程 >什麼是EventLoop？怎麼測試Node或頁面的效能

什麼是EventLoop？怎麼測試Node或頁面的效能

青灯夜游轉載: 2023-03-03 19:47:492203瀏覽

Event Loop 機制大家應該都有了解。本文利用 EventLoop 去做一個有趣的檢測node或頁面效能的程式碼，順便介紹了一下EventLoop，希望對大家有幫助！什麼是EventLoop？怎麼測試Node或頁面的效能

Event Loop

Event Loop 機制大家應該都有了解。我先重複總結一下。 Node.js 和 Javascript 的 Event Loop 不太一樣，直覺上是多了 setImmediate 和 process.nextTick 兩個 API。其次是因為執行時間不一樣，Html Standrad 裡面會考慮多頁面、DOM操作等不同來源會有不同的 task queue 。而 Node.js Event Loop 中需要考慮的沒這麼多。按照我的理解，雙方在概念上是一致的，可以如此概括（或看這裡）：

task queue 任務隊列。有些事件等會被定義為任務，很多時候會被稱為 MacroTask（巨集任務）與 MicroTask 進行對應。每次會取得隊頭的 task 進行執行。
microtask queue 微任務佇列。會有一個微任務佇列，一個 Task 內一般會執行清空微任務佇列。
如此往復。

效能測量

在上面的了解之後，有一個簡單的對效能進行測量的方法：每秒內完成了多少次Event Loop 循環，或執行了多少個MacroTask，這樣我們大致就能知道程式碼中同步的程式碼的執行情況。 測試函數

class MacroTaskChecker {
    constructor(macroTaskDispatcher, count = 1000, cb = () => { }) {
        this.macroTaskDispatcher = macroTaskDispatcher
        this.COUNT = count
        this.cb = cb
    }
    start(cb) {
        this.cb = cb || this.cb
        this.stop = false
        const scope = () => {
            let count = this.COUNT
            const startTime = performance.now()
            const fn = () => {
                count--
                if (count > 0) this.macroTaskDispatcher(fn)
                else {
                    const endTime = performance.now()
                    // 执行 COUNT 次宏任务之后 计算平均每秒执行了多少个
                    this.cb({
                        avg: this.COUNT / (endTime - startTime) * 1000,
                        timestamp: endTime
                    })
                    !this.stop && this.macroTaskDispatcher(scope)
                }
            }
            this.macroTaskDispatcher(fn)
        }
        scope()
    }

    stop() {
        this.stop = true
    }
}

之後，執行一些死迴圈去測試是否能偵測到密集同步程式碼執行。

function meaninglessRun(time) {
    console.time(&#39;meaninglessRun&#39;)
    for (let i = time; i--; i > 0) {
        // do nothing
    }
    console.timeEnd(&#39;meaninglessRun&#39;)
}

setTimeout(() => {
    meaninglessRun(1000 * 1000 * 1000)
}, 1000 * 5)

setTimeout(() => {
    checker.stop()
    console.log(&#39;stop&#39;)
}, 1000 * 20)

setTimeout#

const checker = new MacroTaskChecker(setTimeout, 100)

checker.start(v => console.log(`time: ${v.timestamp.toFixed(2)} avg: ${v.avg.toFixed(2)}`))

從輸出能明顯看到同步阻塞的時候avg是下降的。不過在 browser 和 node.js 上測試兩邊會有明顯差距。【相關教學推薦：nodejs影片教學】

// node.js
time: 4837.47 avg: 825.14
time: 4958.18 avg: 829.83
meaninglessRun: 918.626ms
time: 6001.69 avg: 95.95
time: 6125.72 avg: 817.18
time: 6285.07 avg: 635.16
// browser
time: 153529.90 avg: 205.21
time: 154023.40 avg: 204.46
meaninglessRun: 924.463ms
time: 155424.00 avg: 71.62
time: 155908.80 avg: 208.29
time: 156383.70 avg: 213.04

雖然達成我們的目的，但是使用 setTimeout 是不完全能準確記錄下每一個任務的。根據 HTML Standrad 和 MDN 的說法，setTimeout 最少的會等待4ms。從這個角度看browser avg * 4ms

\approx

#≈

# 1000ms。而 node.js 應該是沒有遵循 browser 那邊的約定，但是也沒有執行到記錄每一個loop。 setImmediate

#如果使用node.js 的setImmediate：

const checker = new MacroTaskChecker(setImmediate, 1000 * 10)

可以看到執行次數大概高出 Node.js

setTimeout

一個量級：<pre class="brush:js;toolbar:false;">time: 4839.71 avg: 59271.54 time: 5032.99 avg: 51778.84 meaninglessRun: 922.182ms time: 6122.44 avg: 9179.95 time: 6338.32 avg: 46351.38 time: 6536.66 avg: 50459.77</pre>按照Node.js 文件中的解釋，

setImmediate ### 會在每一個loop (phase) 的check 階段執行。使用 ###setImmediate### 應該是能準確記錄每一次 Loop 的。我這台機器大概是 40000 到 60000 之間的循環次數。 ###############window.postMessage################在browser 上因為沒有###setImmediate### 我們可以依照MDN 上的指引使用###window.postMessage### 實作一個。 ###

如果想在浏览器中实现 0ms 延时的定时器，你可以参考这里所说的 window.postMessage()

const fns = []
window.addEventListener("message", () => {
    const currentFns = [...fns]
    fns.length = 0
    currentFns.forEach(fn => fn())
}, true);
function messageChannelMacroTaskDispatcher(fn) {
    fns.push(fn)
    window.postMessage(1)
}

可以看到和 node.js setImmediate 量级是一致的。

time: 78769.70 avg: 51759.83
time: 78975.60 avg: 48614.49
meaninglessRun: 921.143 ms
time: 80111.50 avg: 8805.14
time: 80327.00 avg: 46425.26
time: 80539.10 avg: 47169.81

MessageChannel

browser

理论上 browser 使用 MessageChannel 应该也是可以的，还避免了无效的消息被其他 window.addEventListener("message", handler) 接收：

const { port1, port2 } = new MessageChannel();
const fns = []
port1.onmessage = () => {
    const currentFns = [...fns]
    fns.length = 0
    currentFns.forEach(fn => fn())
};
function messageChannelMacroTaskDispatcher(fn) {
    fns.push(fn)
    port2.postMessage(1)
}

不是很懂为啥会比 window.postMessage 频繁一点，同时启动两个 checker 的话可以看到 log 是成对出现的，也就是说一个loop内大家都只执行了一次。我猜测是 window.postMessage 的实现方式消耗会大一些。

time: 54974.80 avg: 68823.12
time: 55121.00 avg: 68493.15
meaninglessRun: 925.160888671875 ms
time: 56204.60 avg: 9229.35
time: 56353.00 avg: 67430.88
time: 56503.10 avg: 66666.67
// 一起执行 wp=window.postMessage mc=MessageChannel
wp time: 43307.90 avg: 25169.90
mc time: 43678.40 avg: 27005.13
wp time: 43678.60 avg: 26990.55
mc time: 44065.80 avg: 25833.12
wp time: 44066.00 avg: 25819.78
mc time: 44458.40 avg: 25484.20

node

在 node.js 上也有 MessageChannel ，是否也可以用来测量loop次数呢？

mc time: 460.99 avg: 353930.80
mc time: 489.52 avg: 355088.11
mc time: 520.30 avg: 326384.64
mc time: 551.78 avg: 320427.29

量级很不正常。理论上不应该超过 setImmediate 的。如果同时启动 setImmediate 和 setTimeout 的 checker:

...
(messagechannel) time: 1231.10 avg: 355569.31
(messagechannel) time: 1260.14 avg: 345825.77
(setImmediate) time: 1269.95 avg: 339.27
(setTimeout) time: 1270.09 avg: 339.13
(messagechannel) time: 1293.80 avg: 298141.74
(messagechannel) time: 1322.50 avg: 349939.04
...

很明显跟不是宏任务了。我猜测 MessageChannel 在 node.js 被归入到跟 socket 等同级别了，就是超出阈值之后的任务会移动到下一个loop中。

总结

使用这种方式去检测性能还挺有趣的，正式使用的话这个指标感觉过于不稳定（即使什么都没做都会有20%-30%的振动）。推荐和其他正经的办法（比如 performance 等）结合。

同时这种方式非常有可能影响正常的 Event Loop，比如 Node.js 中会有一个 pull 的阶段，在执行完全部微任务后，没有任何 timer 的话是会停留在这个阶段，准备马上执行下一个出现的微任务。

顺便复习了下 Event Loop。没想到的是 MessageChannel 在两边的差距居然有这么大。

更多node相关知识，请访问：nodejs 教程！

以上是什麼是EventLoop？怎麼測試Node或頁面的效能的詳細內容。更多資訊請關注PHP中文網其他相關文章！

JavaScript node.js html 循环 Event JS 事件 dom

陳述：

本文轉載於：juejin.cn。如有侵權，請聯絡admin@php.cn刪除

上一篇：詳解如何以JS實現覆蓋浮水印效果下一篇：詳解如何以JS實現覆蓋浮水印效果

看更多