Skip to content

Commit 061df5c

Browse files
committed
update docs
1 parent 7080c8c commit 061df5c

1 file changed

Lines changed: 50 additions & 6 deletions

File tree

doc/api/perf_hooks.md

Lines changed: 50 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1705,23 +1705,40 @@ are not guaranteed to reflect any correct state of the event loop.
17051705

17061706
<!-- YAML
17071707
added: v11.10.0
1708+
changes:
1709+
- version: REPLACEME
1710+
pr-url: https://github.com/nodejs/node/pull/XXXXX
1711+
description: Added the `native` option.
17081712
-->
17091713

17101714
* `options` {Object}
17111715
* `resolution` {number} The sampling rate in milliseconds. Must be greater
1712-
than zero. **Default:** `10`.
1716+
than zero. Only used when `native` is `false`. **Default:** `10`.
1717+
* `native` {boolean} When `true`, uses libuv's `uv_check_t` handle and
1718+
`uv_metrics_idle_time()` to measure the busy time of each event loop
1719+
iteration directly, instead of relying on a sampling timer. **Default:**
1720+
`false`.
17131721
* Returns: {IntervalHistogram}
17141722

17151723
_This property is an extension by Node.js. It is not available in Web browsers._
17161724

17171725
Creates an `IntervalHistogram` object that samples and reports the event loop
17181726
delay over time. The delays will be reported in nanoseconds.
17191727

1720-
Using a timer to detect approximate event loop delay works because the
1721-
execution of timers is tied specifically to the lifecycle of the libuv
1722-
event loop. That is, a delay in the loop will cause a delay in the execution
1723-
of the timer, and those delays are specifically what this API is intended to
1724-
detect.
1728+
Two measurement strategies are available:
1729+
1730+
**Timer-based (default, `native: false`):** Uses a repeating timer that fires
1731+
every `resolution` milliseconds. A delay in the loop causes a corresponding
1732+
delay in timer execution, and that difference is recorded. This approach
1733+
samples the event loop at a fixed rate and is suitable for coarse-grained
1734+
monitoring.
1735+
1736+
**Native (`native: true`):** Registers a libuv `uv_check_t` handle that fires
1737+
after every I/O poll phase. Each firing computes the busy time for that
1738+
iteration as the total elapsed time minus the time spent waiting in the I/O
1739+
poll (obtained from `uv_metrics_idle_time()`). This provides a per-iteration
1740+
measurement without any sampling interval overhead. The `resolution` option
1741+
has no effect in this mode.
17251742

17261743
```mjs
17271744
import { monitorEventLoopDelay } from 'node:perf_hooks';
@@ -1754,6 +1771,33 @@ console.log(h.percentile(50));
17541771
console.log(h.percentile(99));
17551772
```
17561773

1774+
Using the native mode:
1775+
1776+
```mjs
1777+
import { monitorEventLoopDelay } from 'node:perf_hooks';
1778+
1779+
const h = monitorEventLoopDelay({ native: true });
1780+
h.enable();
1781+
// Do something.
1782+
h.disable();
1783+
console.log(h.min);
1784+
console.log(h.max);
1785+
console.log(h.mean);
1786+
console.log(h.percentile(99));
1787+
```
1788+
1789+
```cjs
1790+
const { monitorEventLoopDelay } = require('node:perf_hooks');
1791+
const h = monitorEventLoopDelay({ native: true });
1792+
h.enable();
1793+
// Do something.
1794+
h.disable();
1795+
console.log(h.min);
1796+
console.log(h.max);
1797+
console.log(h.mean);
1798+
console.log(h.percentile(99));
1799+
```
1800+
17571801
## `perf_hooks.timerify(fn[, options])`
17581802

17591803
<!-- YAML

0 commit comments

Comments
 (0)