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

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

Event Loop

Event Loop 機制大家應該都有了解。我先重複總結一下。

Node.js 和 Javascript 的 Event Loop 不太一樣，直觀上是多了 setImmediate 和 process.nextTick 兩個 API。其次是由於執行時不一樣，裡面會考慮多頁面、DOM操作等不同來源會有不同的 task queue 。而中需要考慮的沒這麼多。

按照我的理解，雙方在概念上是一致的，可以如此概括（或者看）：

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('meaninglessRun')
    for (let i = time; i--; i > 0) {
        // do nothing
    }
    console.timeEnd('meaninglessRun')
}

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

setTimeout(() => {
    checker.stop()
    console.log('stop')
}, 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 上測試兩邊會有明顯差距。【相關教學推薦：】

// 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 是不完全能準確記錄下每一個任務的。根據和的說法，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 一個量級：

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
登入後複製

按照 Node.js 檔案中的，setImmediate 會在每一個 loop (phase) 的 check 階段執行。使用 setImmediate 應該是能準確記錄每一次 Loop 的。我這臺機器大概是 40000 到 60000 之間的迴圈次數。

window.postMessage

在 browser 上由於沒有 setImmediate 我們可以按照 MDN 上的指引使用 window.postMessage 實現一個。

如果想在瀏覽器中實現 0ms 延時的定時器，你可以參考所說的

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相關知識，請存取：！

以上就是什麼是EventLoop？怎麼測試Node或頁面的效能的詳細內容，更多請關注TW511.COM其它相關文章！