ホームページ > 記事 > ウェブフロントエンド > イベントループとは何ですか?ノードまたはページのパフォーマンスをテストする方法
イベント ループ メカニズムについては誰もが知っておくべきです。この記事では、EventLoop を使用して、ノードまたはページのパフォーマンスを検出するための興味深いコードを作成します。ちなみに、EventLoop についても紹介します。皆さんの参考になれば幸いです。
イベント ループの仕組みは誰もが知っているはずです。最初に概要を繰り返します。
Node.js のイベント ループは Javascript のイベント ループとは異なり、直感的には、さらに 2 つの API、setImmediate と process.nextTick があります。次に、ランタイムが異なるため、Html Standrad は、複数のページや DOM 操作など、ソースごとに異なるタスク キューを考慮します。 Node.js イベント ループ では、考慮すべきことはそれほど多くありません。
私の理解によれば、この 2 つの関係者は概念的に一貫しており、次のように要約できます (または ここを参照):
タスク キュー タスク列 。一部のイベントはタスクとして定義されており、MicroTask に対応して 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)
<span style="font-size: 18px;"><pre class="brush:js;toolbar:false;">const checker = new MacroTaskChecker(setTimeout, 100)
checker.start(v => console.log(`time: ${v.timestamp.toFixed(2)} avg: ${v.avg.toFixed(2)}`))</pre></span>出力から、同期がブロックされると avg が減少することが明確にわかります。ただし、ブラウザーとnode.jsでの2つのテストには明らかな違いがあります。 [関連チュートリアルの推奨事項: 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 は少なくとも 4 ミリ秒待機します。この角度からブラウザで見た場合、平均 * 4ms ≈
setImmediate<span style="font-size: 18px;"></span>node.js の setImmediate を使用する場合:
const checker = new MacroTaskChecker(setImmediate, 1000 * 10)
実行回数がNode.jsよりも約1桁多いことがわかります 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 を使用すると、すべてのループを正確に記録できるはずです。私のマシンのサイクル数はおそらく 40,000 ～ 60,000 の間です。
<span style="font-size: 18px;"></span>ブラウザには setImmediate がないため、次のことができます。 MDN に従ってください。この手順では、
を使用して実装します。 <blockquote><p>如果想在浏览器中实现 0ms 延时的定时器，你可以参考<a href="//m.sbmmt.com/link/b9e825688da5c08ccbceeb3b4d5edd5a" target="_blank" title="https://dbaron.org/log/20100309-faster-timeouts" ref="nofollow noopener noreferrer">这里</a>所说的 <a href="//m.sbmmt.com/link/c9bff4aee928935151b2eee3cafeed2b" target="_blank" title="https://developer.mozilla.org/zh-CN/docs/Web/API/Window/postMessage" ref="nofollow noopener noreferrer"><code>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
<span style="font-size: 18px;">MessageChannel</span>
理论上 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.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 教程！
以上がイベントループとは何ですか?ノードまたはページのパフォーマンスをテストする方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。