New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

perf_hooks: implementation of Performance Timing API #14680

Closed
wants to merge 1 commit into
base: master
from

Conversation

@jasnell
Member

jasnell commented Aug 7, 2017

An initial implementation of the Performance Timing API for Node.js. This is the same Performance Timing API implemented by modern browsers with a number of Node.js specific properties. The User Timing mark() and measure() APIs are implemented, as is a Node.js specific flavor of the Frame Timing for measuring event loop duration.

const { performance } = require('perf_hooks');
performance.mark('A');
setTimeout(() => {
  performance.mark('B');
  performance.measure('A to B', 'A', 'B');
  const entry = performance.getEntriesByName('A to B', 'measure');
  console.log(entry.duration);
}, 10000);

The implementation is at the native layer and makes use of uv_hrtime().
This should enable eventual integeration with the Inspector protocol
so that the performance timeline can be viewed in debugging tools.

The implementation is extensible and should allow us to add new
performance entry types as we go (e.g. for measuring i/o perf,
etc).

Documentation and a test are provided.

/cc @mcollina

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

perf_hooks

@jasnell jasnell added the semver-minor label Aug 7, 2017

@jasnell jasnell requested review from mcollina and addaleax Aug 7, 2017

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Aug 7, 2017

Member

Suggestion: Run make coverage and be sure that all the new code paths are covered by tests.

Member

Trott commented Aug 7, 2017

Suggestion: Run make coverage and be sure that all the new code paths are covered by tests.

@mscdex

This comment has been minimized.

Show comment
Hide comment
@mscdex

mscdex Aug 7, 2017

Contributor

Why deviate from browsers by putting this on process instead of making it "global" like we do with setTimeout, setInterval, etc.?

Contributor

mscdex commented Aug 7, 2017

Why deviate from browsers by putting this on process instead of making it "global" like we do with setTimeout, setInterval, etc.?

@addaleax

I’ll try to give this a full review later :)

Show outdated Hide outdated doc/api/process.md
Show outdated Hide outdated lib/internal/performance.js
@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Aug 7, 2017

Member

@mscdex ... every time I suggest adding a global, people say no.

Member

jasnell commented Aug 7, 2017

@mscdex ... every time I suggest adding a global, people say no.

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Aug 7, 2017

Member

@Trott ... I will be :-)

Member

jasnell commented Aug 7, 2017

@Trott ... I will be :-)

@mscdex

This comment has been minimized.

Show comment
Hide comment
@mscdex

mscdex Aug 8, 2017

Contributor

@jasnell That might be the case in general, but for APIs shared with browsers it makes more sense to me IMHO. I can't imagine there would be that many people negatively affected by adding it as a "global" (real or otherwise).

Contributor

mscdex commented Aug 8, 2017

@jasnell That might be the case in general, but for APIs shared with browsers it makes more sense to me IMHO. I can't imagine there would be that many people negatively affected by adding it as a "global" (real or otherwise).

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Aug 8, 2017

Member

@mscdex ... I don't disagree, but I've run into opposition for URL, TextEncoder and TextDecoder, all of which are globals in the browser.

Member

jasnell commented Aug 8, 2017

@mscdex ... I don't disagree, but I've run into opposition for URL, TextEncoder and TextDecoder, all of which are globals in the browser.

Show outdated Hide outdated test/parallel/test-performance.js
Show outdated Hide outdated test/parallel/test-performance.js
Show outdated Hide outdated src/node.cc
Show outdated Hide outdated src/node.cc
Show outdated Hide outdated src/node.cc
@refack

This comment has been minimized.

Show comment
Hide comment
@refack

refack Aug 8, 2017

Member

Hooking it on process seems strange... IMHO either set it as global or make it a module.

Member

refack commented Aug 8, 2017

Hooking it on process seems strange... IMHO either set it as global or make it a module.

@TimothyGu

Code review will come later...

Show outdated Hide outdated doc/api/process.md
Show outdated Hide outdated doc/api/process.md
Show outdated Hide outdated doc/api/process.md
Show outdated Hide outdated doc/api/process.md
@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Aug 8, 2017

Member

A couple of things that still need to be done (in case anyone wants to help ;-) ...)

  1. Implement PerformanceObserver .. I've got a couple of ideas on this already so may get to it as early as tomorrow.

  2. Ensure that the list of PerformanceEntry instances are in proper chronological order. PerformanceMeasure instances in particular.

  3. Implement toJSON() on PerformanceEntry

Member

jasnell commented Aug 8, 2017

A couple of things that still need to be done (in case anyone wants to help ;-) ...)

  1. Implement PerformanceObserver .. I've got a couple of ideas on this already so may get to it as early as tomorrow.

  2. Ensure that the list of PerformanceEntry instances are in proper chronological order. PerformanceMeasure instances in particular.

  3. Implement toJSON() on PerformanceEntry

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Aug 8, 2017

Member

Putting this in a new core module makes sense. Currently, the perf_hooks module name is not taken on npm and has good alignment with async_hooks. More obvious other options like performance and perf are already taken.

Member

jasnell commented Aug 8, 2017

Putting this in a new core module makes sense. Currently, the perf_hooks module name is not taken on npm and has good alignment with async_hooks. More obvious other options like performance and perf are already taken.

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Aug 9, 2017

Member

Ok, I've refactored this to use a new perf_hooks module...

e.g.

const {
  performance,
  PerformanceObserver
} = require('perf_hooks');

performance.mark('test');
Member

jasnell commented Aug 9, 2017

Ok, I've refactored this to use a new perf_hooks module...

e.g.

const {
  performance,
  PerformanceObserver
} = require('perf_hooks');

performance.mark('test');
Show outdated Hide outdated doc/api/perf_hooks.md
Show outdated Hide outdated doc/api/perf_hooks.md
Show outdated Hide outdated doc/api/perf_hooks.md
* {number}
The high resolution millisecond timestamp marking the starting time of the

This comment has been minimized.

@thefourtheye

thefourtheye Aug 9, 2017

Contributor

In few other places in the documentation, high resolution is hyphenated. Perhaps we should unhyphenate them?

@thefourtheye

thefourtheye Aug 9, 2017

Contributor

In few other places in the documentation, high resolution is hyphenated. Perhaps we should unhyphenate them?

Show outdated Hide outdated doc/api/perf_hooks.md
Show outdated Hide outdated doc/api/perf_hooks.md
Show outdated Hide outdated doc/api/perf_hooks.md
@@ -1852,11 +1852,11 @@ cases:
[Cluster]: cluster.html
[Duplex]: stream.html#stream_duplex_and_transform_streams
[LTS]: https://github.com/nodejs/LTS/
[note on process I/O]: process.html#process_a_note_on_process_i_o

This comment has been minimized.

@thefourtheye

thefourtheye Aug 9, 2017

Contributor

Unrelated change?

@thefourtheye

thefourtheye Aug 9, 2017

Contributor

Unrelated change?

Show outdated Hide outdated doc/api/perf_hooks.md
Show outdated Hide outdated src/node_perf.h
@mcollina

LGTM with some nits.

Show outdated Hide outdated lib/perf_hooks.js
Show outdated Hide outdated lib/perf_hooks.js
Show outdated Hide outdated lib/perf_hooks.js
Show outdated Hide outdated lib/perf_hooks.js
@refack

This comment has been minimized.

Show comment
Hide comment
@refack

refack Aug 9, 2017

Member

I'm +1 on perf_hooks as a module.

Member

refack commented Aug 9, 2017

I'm +1 on perf_hooks as a module.

@refack

This comment has been minimized.

Show comment
Hide comment
@refack

refack Aug 9, 2017

Member

I have another high level question - how does this integrate with 14347 async-hooks: add trace events to AsyncWrap

Member

refack commented Aug 9, 2017

I have another high level question - how does this integrate with 14347 async-hooks: add trace events to AsyncWrap

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Aug 10, 2017

Member

@refack ... at this point it doesn't

Member

jasnell commented Aug 10, 2017

@refack ... at this point it doesn't

* {string}
The type of the performance entry. Current it may be one of: `'node'`, `'mark'`,

This comment has been minimized.

@vsemozhetbyt

vsemozhetbyt Aug 10, 2017

Member

Current -> Currently?

@vsemozhetbyt

vsemozhetbyt Aug 10, 2017

Member

Current -> Currently?

const obs = new PerformanceObserver((list) => {
console.log(list.getEntries()[0].duration);
obs.disconnect();
performance.clearFunctions();

This comment has been minimized.

@vsemozhetbyt

vsemozhetbyt Aug 10, 2017

Member

Need not this call also be added in the Class: PerformanceObserver(callback) example below (lines 433-436)?

@vsemozhetbyt

vsemozhetbyt Aug 10, 2017

Member

Need not this call also be added in the Class: PerformanceObserver(callback) example below (lines 433-436)?

Show outdated Hide outdated lib/perf_hooks.js
Show outdated Hide outdated lib/perf_hooks.js
added: REPLACEME
-->
* `options` {Object}
* `entryTypes` {Array} An array of strings identifying the types of

This comment has been minimized.

@joyeecheung

joyeecheung Aug 10, 2017

Member

{string[]}?

@joyeecheung

joyeecheung Aug 10, 2017

Member

{string[]}?

Show outdated Hide outdated doc/api/perf_hooks.md
@TimothyGu

This comment has been minimized.

Show comment
Hide comment
@TimothyGu

TimothyGu Aug 10, 2017

Member

I've got the same concern as @refack: how does this compare/interact with existing means of measuring performance? While I'm all for implementing browser APIs in Node.js, duplicated features are not a good thing just in general.

Member

TimothyGu commented Aug 10, 2017

I've got the same concern as @refack: how does this compare/interact with existing means of measuring performance? While I'm all for implementing browser APIs in Node.js, duplicated features are not a good thing just in general.

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Aug 10, 2017

Member

@TimothyGu ... I've got it in my todo list to look through and reconcile the two as much as possible

Member

jasnell commented Aug 10, 2017

@TimothyGu ... I've got it in my todo list to look through and reconcile the two as much as possible

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Aug 10, 2017

Member

One very important difference between the two is that this API is expected to always be available, whereas enabling tracing requires a command-line flag and is not currently available to user code. Internally, these mechanisms can likely be unified, and I'm already looking to see if trace events (when enabled) can be made to appear within the performance timeline without too much trouble.

Member

jasnell commented Aug 10, 2017

One very important difference between the two is that this API is expected to always be available, whereas enabling tracing requires a command-line flag and is not currently available to user code. Internally, these mechanisms can likely be unified, and I'm already looking to see if trace events (when enabled) can be made to appear within the performance timeline without too much trouble.

@matthewloring

This comment has been minimized.

Show comment
Hide comment
@matthewloring

matthewloring Aug 12, 2017

Contributor

This work does seem to have a lot of overlap with trace event and it would be good to figure out if/how the two fit together. The trace event system already records garbage collection information with lower performance overhead (no need for GC callbacks). Would it make sense to use trace event data as the source of this timing information? Or to expand this API to serve as the programatic API for trace event (nodejs/node-eps#48)? Maybe the browser folks have insight into how these two systems work together in the browser. \cc @fmeawad @paulirish

Contributor

matthewloring commented Aug 12, 2017

This work does seem to have a lot of overlap with trace event and it would be good to figure out if/how the two fit together. The trace event system already records garbage collection information with lower performance overhead (no need for GC callbacks). Would it make sense to use trace event data as the source of this timing information? Or to expand this API to serve as the programatic API for trace event (nodejs/node-eps#48)? Maybe the browser folks have insight into how these two systems work together in the browser. \cc @fmeawad @paulirish

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Aug 12, 2017

Member
Member

jasnell commented Aug 12, 2017

@ofrobots

This comment has been minimized.

Show comment
Hide comment
@ofrobots

ofrobots Aug 14, 2017

Contributor

/cc @nodejs/diagnostics

I would really like to see some understanding of how this would integrate with trace-event before this lands.

Contributor

ofrobots commented Aug 14, 2017

/cc @nodejs/diagnostics

I would really like to see some understanding of how this would integrate with trace-event before this lands.

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Aug 23, 2017

Member

My apologies, I did not interpret your one comment as an objection and I certainly did not ignore it. I'm sorry if I misinterpreted your comment. I have found that using the big red X does make it easier to distinguish objections. I ended up rewriting most of the implementation in order to keep it as minimal as possible and removed a significant chunk of the functionality. Thus far all of the reaction and feedback I've had on this has been overwhelmingly positive. This went through all the regular review processes so I see no reason to back it out, but I could certainly see a case for marking it experimental so we have more time to make a long term support decision. I'm happy to open a PR doing so.

Member

jasnell commented Aug 23, 2017

My apologies, I did not interpret your one comment as an objection and I certainly did not ignore it. I'm sorry if I misinterpreted your comment. I have found that using the big red X does make it easier to distinguish objections. I ended up rewriting most of the implementation in order to keep it as minimal as possible and removed a significant chunk of the functionality. Thus far all of the reaction and feedback I've had on this has been overwhelmingly positive. This went through all the regular review processes so I see no reason to back it out, but I could certainly see a case for marking it experimental so we have more time to make a long term support decision. I'm happy to open a PR doing so.

@Fishrock123

This comment has been minimized.

Show comment
Hide comment
@Fishrock123

Fishrock123 Aug 24, 2017

Member

I have found that using the big red X does make it easier to distinguish objections.

It was my understanding that using it in that way should be avoided? Perhaps i misunderstood how we use it these days.

Member

Fishrock123 commented Aug 24, 2017

I have found that using the big red X does make it easier to distinguish objections.

It was my understanding that using it in that way should be avoided? Perhaps i misunderstood how we use it these days.

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Aug 24, 2017

Member

For new contributors perhaps. And not necessarily avoided as much as used with discretion so as not to discourage or overwhelm a new contributor.... neither of which are concerns for me.

Member

jasnell commented Aug 24, 2017

For new contributors perhaps. And not necessarily avoided as much as used with discretion so as not to discourage or overwhelm a new contributor.... neither of which are concerns for me.

@Fishrock123

This comment has been minimized.

Show comment
Hide comment
@Fishrock123

Fishrock123 Aug 24, 2017

Member

I don't really have any energy left today but I'll put up an issue about this tomorrow.

Member

Fishrock123 commented Aug 24, 2017

I don't really have any energy left today but I'll put up an issue about this tomorrow.

@AndreasMadsen

This comment has been minimized.

Show comment
Hide comment
@AndreasMadsen

AndreasMadsen Aug 24, 2017

Member

@jasnell @Fishrock123 I too feel this went too fast. Adding a new module should first happen as a node-EPS which is then discusssed and agreed by the CTC. Then the implementation should happen. We spend at least a year discussing async_hooks, I don't see a need for that much discussion here but 17 days is just too fast.

Issues as to how this integrates with trace events and if we want to implement a W3C API are best discussed in a node-EPS.

Also, please don't interpret my concerns as a disagreement on the module or the implementantion, I don't understand the Performance Timing API well enogth to comment on that. It is simply the consensus approach I disagree with.

I have been holiday for most of this period, thus I haven't raised any concerns before now.

Member

AndreasMadsen commented Aug 24, 2017

@jasnell @Fishrock123 I too feel this went too fast. Adding a new module should first happen as a node-EPS which is then discusssed and agreed by the CTC. Then the implementation should happen. We spend at least a year discussing async_hooks, I don't see a need for that much discussion here but 17 days is just too fast.

Issues as to how this integrates with trace events and if we want to implement a W3C API are best discussed in a node-EPS.

Also, please don't interpret my concerns as a disagreement on the module or the implementantion, I don't understand the Performance Timing API well enogth to comment on that. It is simply the consensus approach I disagree with.

I have been holiday for most of this period, thus I haven't raised any concerns before now.

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Aug 24, 2017

Member

We likely should refine some of the process guideline here then. Perhaps a rule that prs that add a new Module are always landed as experimental first and must go through a longer period of review. I'd be good with that :)

Member

jasnell commented Aug 24, 2017

We likely should refine some of the process guideline here then. Perhaps a rule that prs that add a new Module are always landed as experimental first and must go through a longer period of review. I'd be good with that :)

@evanlucas

This comment has been minimized.

Show comment
Hide comment
@evanlucas

evanlucas Aug 24, 2017

Member

I agree that this may have landed prematurely, especially considering @Fishrock123's concern appears to have been ignored...

Looks like @ofrobots had some concerns as well? EDIT

Member

evanlucas commented Aug 24, 2017

I agree that this may have landed prematurely, especially considering @Fishrock123's concern appears to have been ignored...

Looks like @ofrobots had some concerns as well? EDIT

@ofrobots

This comment has been minimized.

Show comment
Hide comment
@ofrobots

ofrobots Aug 24, 2017

Contributor

My concerns around interoperability with lower level trace events were adequately addressed by @jasnell.

Contributor

ofrobots commented Aug 24, 2017

My concerns around interoperability with lower level trace events were adequately addressed by @jasnell.

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Aug 24, 2017

Member

No one's concerns were ignored at all! As I said before it wasn't clear to me that @Fishrock123 was making an actual objection. My apologies for misinterpreting his comment.

As for what @ofrobots mentioned, I dug in pretty deep in that and investigated integration with trace events and discovered that the still experimental, still unfinished trace event support does not yet implement the necessary functionality. Once it does integration will be trivial (as in maybe five lines of code) but getting trace events to do the right thing will not be easy.

Member

jasnell commented Aug 24, 2017

No one's concerns were ignored at all! As I said before it wasn't clear to me that @Fishrock123 was making an actual objection. My apologies for misinterpreting his comment.

As for what @ofrobots mentioned, I dug in pretty deep in that and investigated integration with trace events and discovered that the still experimental, still unfinished trace event support does not yet implement the necessary functionality. Once it does integration will be trivial (as in maybe five lines of code) but getting trace events to do the right thing will not be easy.

@AndreasMadsen

This comment has been minimized.

Show comment
Hide comment
@AndreasMadsen

AndreasMadsen Aug 24, 2017

Member

We likely should refine some of the process guideline here then. Perhaps a rule that prs that add a new Module are always landed as experimental first and must go through a longer period of review. I'd be good with that :)

I agree. The primary mistake was that nobody requested an EPS. But a more clear guideline would have prevented that human mistake. The current guideline is:

EPs are used when the proposed feature is a substantial new API, is too broad or would modify APIs heavily. Minor changes do not require writing an EP. What is and isn't minor is subjective, so as a general rule, users should discuss the proposal briefly by other means (issue tracker, mailing list or IRC) and write an EP when requested by the Node core team.

It could at the very least add some obvious examples, like "adding a module" or "breaking a stable API".

I will let @Fishrock123 write up the issue and then we can act from there.

Member

AndreasMadsen commented Aug 24, 2017

We likely should refine some of the process guideline here then. Perhaps a rule that prs that add a new Module are always landed as experimental first and must go through a longer period of review. I'd be good with that :)

I agree. The primary mistake was that nobody requested an EPS. But a more clear guideline would have prevented that human mistake. The current guideline is:

EPs are used when the proposed feature is a substantial new API, is too broad or would modify APIs heavily. Minor changes do not require writing an EP. What is and isn't minor is subjective, so as a general rule, users should discuss the proposal briefly by other means (issue tracker, mailing list or IRC) and write an EP when requested by the Node core team.

It could at the very least add some obvious examples, like "adding a module" or "breaking a stable API".

I will let @Fishrock123 write up the issue and then we can act from there.

@targos

This comment has been minimized.

Show comment
Hide comment
@targos

targos Aug 25, 2017

Member

I think that this should have at least had another formal LGTM before landing, even if it came again from @mcollina. I didn't follow the development of this PR closely but it looks like between Matteo's review and the actual landing, a lot of changes were done (ref).

Member

targos commented Aug 25, 2017

I think that this should have at least had another formal LGTM before landing, even if it came again from @mcollina. I didn't follow the development of this PR closely but it looks like between Matteo's review and the actual landing, a lot of changes were done (ref).

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Aug 25, 2017

Member

Good feedback for next time. Thanks @targos :)

Member

jasnell commented Aug 25, 2017

Good feedback for next time. Thanks @targos :)

@mcollina

This comment has been minimized.

Show comment
Hide comment
@mcollina

mcollina Aug 25, 2017

Member

Confirming the LGTM.

BTW, I think also @refack approved this.

Member

mcollina commented Aug 25, 2017

Confirming the LGTM.

BTW, I think also @refack approved this.

addaleax added a commit to addaleax/ayo that referenced this pull request Aug 25, 2017

perf_hooks: implementation of the perf timing API
An initial implementation of the Performance Timing API for Node.js.
This is the same Performance Timing API implemented by modern browsers
with a number of Node.js specific properties. The User Timing mark()
and measure() APIs are implemented, garbage collection timing, and
node startup milestone timing.

```js
const { performance } = require('perf_hooks');

performance.mark('A');
setTimeout(() => {
  performance.mark('B');
  performance.measure('A to B', 'A', 'B');
  const entry = performance.getEntriesByName('A to B', 'measure')[0];
  console.log(entry.duration);
}, 10000);
```

The implementation is at the native layer and makes use of uv_hrtime().
This should enable *eventual* integration with things like Tracing
and Inspection.

The implementation is extensible and should allow us to add new
performance entry types as we go (e.g. for measuring i/o perf,
etc).

Documentation and a test are provided.

PR-URL: nodejs/node#14680
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Aug 25, 2017

Member

btw, I've opened #15022 to establish a guideline for next time :-)

Member

jasnell commented Aug 25, 2017

btw, I've opened #15022 to establish a guideline for next time :-)

@refack

This comment has been minimized.

Show comment
Hide comment
@refack

refack Aug 27, 2017

Member

@mcollina I had the same concerns as mentioned above about trace events, but those were addressed.
It was my suggestion to make this into a "module" but that was just the scoping solution that made most sense.
IMHO this should be considered a a single API, not really a new module.

As general feedback postmortem:
I have no objections on this PR (+0)
+1 on it being scoped as a module
+1 on it having being marked as experimental
+1 on red X when reviewing Collaborators
+1 for guidelines

Member

refack commented Aug 27, 2017

@mcollina I had the same concerns as mentioned above about trace events, but those were addressed.
It was my suggestion to make this into a "module" but that was just the scoping solution that made most sense.
IMHO this should be considered a a single API, not really a new module.

As general feedback postmortem:
I have no objections on this PR (+0)
+1 on it being scoped as a module
+1 on it having being marked as experimental
+1 on red X when reviewing Collaborators
+1 for guidelines

addaleax added a commit to ayojs/ayo that referenced this pull request Aug 28, 2017

perf_hooks: implementation of the perf timing API
An initial implementation of the Performance Timing API for Node.js.
This is the same Performance Timing API implemented by modern browsers
with a number of Node.js specific properties. The User Timing mark()
and measure() APIs are implemented, garbage collection timing, and
node startup milestone timing.

```js
const { performance } = require('perf_hooks');

performance.mark('A');
setTimeout(() => {
  performance.mark('B');
  performance.measure('A to B', 'A', 'B');
  const entry = performance.getEntriesByName('A to B', 'measure')[0];
  console.log(entry.duration);
}, 10000);
```

The implementation is at the native layer and makes use of uv_hrtime().
This should enable *eventual* integration with things like Tracing
and Inspection.

The implementation is extensible and should allow us to add new
performance entry types as we go (e.g. for measuring i/o perf,
etc).

Documentation and a test are provided.

PR-URL: nodejs/node#14680
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>

MylesBorins added a commit that referenced this pull request Sep 10, 2017

perf_hooks: implementation of the perf timing API
An initial implementation of the Performance Timing API for Node.js.
This is the same Performance Timing API implemented by modern browsers
with a number of Node.js specific properties. The User Timing mark()
and measure() APIs are implemented, garbage collection timing, and
node startup milestone timing.

```js
const { performance } = require('perf_hooks');

performance.mark('A');
setTimeout(() => {
  performance.mark('B');
  performance.measure('A to B', 'A', 'B');
  const entry = performance.getEntriesByName('A to B', 'measure')[0];
  console.log(entry.duration);
}, 10000);
```

The implementation is at the native layer and makes use of uv_hrtime().
This should enable *eventual* integration with things like Tracing
and Inspection.

The implementation is extensible and should allow us to add new
performance entry types as we go (e.g. for measuring i/o perf,
etc).

Documentation and a test are provided.

PR-URL: #14680
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>

@MylesBorins MylesBorins referenced this pull request Sep 10, 2017

Merged

v8.5.0 proposal #15308

MylesBorins added a commit that referenced this pull request Sep 11, 2017

perf_hooks: implementation of the perf timing API
An initial implementation of the Performance Timing API for Node.js.
This is the same Performance Timing API implemented by modern browsers
with a number of Node.js specific properties. The User Timing mark()
and measure() APIs are implemented, garbage collection timing, and
node startup milestone timing.

```js
const { performance } = require('perf_hooks');

performance.mark('A');
setTimeout(() => {
  performance.mark('B');
  performance.measure('A to B', 'A', 'B');
  const entry = performance.getEntriesByName('A to B', 'measure')[0];
  console.log(entry.duration);
}, 10000);
```

The implementation is at the native layer and makes use of uv_hrtime().
This should enable *eventual* integration with things like Tracing
and Inspection.

The implementation is extensible and should allow us to add new
performance entry types as we go (e.g. for measuring i/o perf,
etc).

Documentation and a test are provided.

PR-URL: #14680
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>

MylesBorins added a commit that referenced this pull request Sep 12, 2017

perf_hooks: implementation of the perf timing API
An initial implementation of the Performance Timing API for Node.js.
This is the same Performance Timing API implemented by modern browsers
with a number of Node.js specific properties. The User Timing mark()
and measure() APIs are implemented, garbage collection timing, and
node startup milestone timing.

```js
const { performance } = require('perf_hooks');

performance.mark('A');
setTimeout(() => {
  performance.mark('B');
  performance.measure('A to B', 'A', 'B');
  const entry = performance.getEntriesByName('A to B', 'measure')[0];
  console.log(entry.duration);
}, 10000);
```

The implementation is at the native layer and makes use of uv_hrtime().
This should enable *eventual* integration with things like Tracing
and Inspection.

The implementation is extensible and should allow us to add new
performance entry types as we go (e.g. for measuring i/o perf,
etc).

Documentation and a test are provided.

PR-URL: #14680
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>

MylesBorins added a commit that referenced this pull request Sep 12, 2017

2017-09-12, Version 8.5.0 (Current)
Notable Changes

* build:
  * Snapshots are now re-enabled in V8
  #14875

* console:
  * Implement minimal `console.group()`.
  #14910

* deps:
  * upgrade libuv to 1.14.1
    #14866
  * update nghttp2 to v1.25.0
    #14955

* dns:
  * Add `verbatim` option to dns.lookup(). When true, results from the
    DNS resolver are passed on as-is, without the reshuffling that
    Node.js otherwise does that puts IPv4 addresses before IPv6
    addresses.
    #14731

* fs:
  * add fs.copyFile and fs.copyFileSync which allows for more efficient
    copying of files.
    #15034

* inspector:
  * Enable async stack traces
    #13870

* module:
  * Add support for ESM. This is currently behind the
    `--experimental-modules` flag and requires the .mjs extension.
    `node --experimental-modules index.mjs`
    #14369

* napi:
  * implement promise
    #14365

* os:
  * Add support for CIDR notation to the output of the
    networkInterfaces() method.
    #14307

* perf_hooks:
  * An initial implementation of the Performance Timing API for
    Node.js. This is the same Performance Timing API implemented by
    modern browsers with a number of Node.js specific properties. The
    User Timing mark() and measure() APIs are implemented, as is a
    Node.js specific flavor of the Frame Timing for measuring event
    loop duration.
    #14680

* tls:
  * multiple PFX in createSecureContext
    [#14793](#14793)

* Added new collaborators:
  * BridgeAR – Ruben Bridgewater

PR-URL: #15308

MylesBorins added a commit that referenced this pull request Sep 12, 2017

2017-09-12, Version 8.5.0 (Current)
Notable Changes

* build:
  * Snapshots are now re-enabled in V8
  #14875

* console:
  * Implement minimal `console.group()`.
  #14910

* deps:
  * upgrade libuv to 1.14.1
    #14866
  * update nghttp2 to v1.25.0
    #14955

* dns:
  * Add `verbatim` option to dns.lookup(). When true, results from the
    DNS resolver are passed on as-is, without the reshuffling that
    Node.js otherwise does that puts IPv4 addresses before IPv6
    addresses.
    #14731

* fs:
  * add fs.copyFile and fs.copyFileSync which allows for more efficient
    copying of files.
    #15034

* inspector:
  * Enable async stack traces
    #13870

* module:
  * Add support for ESM. This is currently behind the
    `--experimental-modules` flag and requires the .mjs extension.
    `node --experimental-modules index.mjs`
    #14369

* napi:
  * implement promise
    #14365

* os:
  * Add support for CIDR notation to the output of the
    networkInterfaces() method.
    #14307

* perf_hooks:
  * An initial implementation of the Performance Timing API for
    Node.js. This is the same Performance Timing API implemented by
    modern browsers with a number of Node.js specific properties. The
    User Timing mark() and measure() APIs are implemented, as is a
    Node.js specific flavor of the Frame Timing for measuring event
    loop duration.
    #14680

* tls:
  * multiple PFX in createSecureContext
    [#14793](#14793)

* Added new collaborators:
  * BridgeAR – Ruben Bridgewater

PR-URL: #15308

MylesBorins added a commit that referenced this pull request Sep 12, 2017

2017-09-12, Version 8.5.0 (Current)
Notable Changes

* build:
  * Snapshots are now re-enabled in V8
  #14875

* console:
  * Implement minimal `console.group()`.
  #14910

* deps:
  * upgrade libuv to 1.14.1
    #14866
  * update nghttp2 to v1.25.0
    #14955

* dns:
  * Add `verbatim` option to dns.lookup(). When true, results from the
    DNS resolver are passed on as-is, without the reshuffling that
    Node.js otherwise does that puts IPv4 addresses before IPv6
    addresses.
    #14731

* fs:
  * add fs.copyFile and fs.copyFileSync which allows for more efficient
    copying of files.
    #15034

* inspector:
  * Enable async stack traces
    #13870

* module:
  * Add support for ESM. This is currently behind the
    `--experimental-modules` flag and requires the .mjs extension.
    `node --experimental-modules index.mjs`
    #14369

* napi:
  * implement promise
    #14365

* os:
  * Add support for CIDR notation to the output of the
    networkInterfaces() method.
    #14307

* perf_hooks:
  * An initial implementation of the Performance Timing API for
    Node.js. This is the same Performance Timing API implemented by
    modern browsers with a number of Node.js specific properties. The
    User Timing mark() and measure() APIs are implemented, as is a
    Node.js specific flavor of the Frame Timing for measuring event
    loop duration.
    #14680

* tls:
  * multiple PFX in createSecureContext
    [#14793](#14793)

* Added new collaborators:
  * BridgeAR – Ruben Bridgewater

PR-URL: #15308

MylesBorins added a commit that referenced this pull request Sep 12, 2017

2017-09-12, Version 8.5.0 (Current)
Notable Changes

* build:
  * Snapshots are now re-enabled in V8
  #14875

* console:
  * Implement minimal `console.group()`.
  #14910

* deps:
  * upgrade libuv to 1.14.1
    #14866
  * update nghttp2 to v1.25.0
    #14955

* dns:
  * Add `verbatim` option to dns.lookup(). When true, results from the
    DNS resolver are passed on as-is, without the reshuffling that
    Node.js otherwise does that puts IPv4 addresses before IPv6
    addresses.
    #14731

* fs:
  * add fs.copyFile and fs.copyFileSync which allows for more efficient
    copying of files.
    #15034

* inspector:
  * Enable async stack traces
    #13870

* module:
  * Add support for ESM. This is currently behind the
    `--experimental-modules` flag and requires the .mjs extension.
    `node --experimental-modules index.mjs`
    #14369

* napi:
  * implement promise
    #14365

* os:
  * Add support for CIDR notation to the output of the
    networkInterfaces() method.
    #14307

* perf_hooks:
  * An initial implementation of the Performance Timing API for
    Node.js. This is the same Performance Timing API implemented by
    modern browsers with a number of Node.js specific properties. The
    User Timing mark() and measure() APIs are implemented, as is a
    Node.js specific flavor of the Frame Timing for measuring event
    loop duration.
    #14680

* tls:
  * multiple PFX in createSecureContext
    [#14793](#14793)

* Added new collaborators:
  * BridgeAR – Ruben Bridgewater

PR-URL: #15308

addaleax added a commit to addaleax/node that referenced this pull request Sep 13, 2017

2017-09-12, Version 8.5.0 (Current)
Notable Changes

* build:
  * Snapshots are now re-enabled in V8
  nodejs#14875

* console:
  * Implement minimal `console.group()`.
  nodejs#14910

* deps:
  * upgrade libuv to 1.14.1
    nodejs#14866
  * update nghttp2 to v1.25.0
    nodejs#14955

* dns:
  * Add `verbatim` option to dns.lookup(). When true, results from the
    DNS resolver are passed on as-is, without the reshuffling that
    Node.js otherwise does that puts IPv4 addresses before IPv6
    addresses.
    nodejs#14731

* fs:
  * add fs.copyFile and fs.copyFileSync which allows for more efficient
    copying of files.
    nodejs#15034

* inspector:
  * Enable async stack traces
    nodejs#13870

* module:
  * Add support for ESM. This is currently behind the
    `--experimental-modules` flag and requires the .mjs extension.
    `node --experimental-modules index.mjs`
    nodejs#14369

* napi:
  * implement promise
    nodejs#14365

* os:
  * Add support for CIDR notation to the output of the
    networkInterfaces() method.
    nodejs#14307

* perf_hooks:
  * An initial implementation of the Performance Timing API for
    Node.js. This is the same Performance Timing API implemented by
    modern browsers with a number of Node.js specific properties. The
    User Timing mark() and measure() APIs are implemented, as is a
    Node.js specific flavor of the Frame Timing for measuring event
    loop duration.
    nodejs#14680

* tls:
  * multiple PFX in createSecureContext
    [#14793](nodejs#14793)

* Added new collaborators:
  * BridgeAR – Ruben Bridgewater

PR-URL: nodejs#15308
`PerformanceNodeTiming` class. If the named `endMark` does not exist, an
error will be thrown.
### performance.nodeFrame

This comment has been minimized.

@sam-github

sam-github Sep 22, 2017

Member

@jasnell I'm not finding this property on the performance object, and I can't find any sign of a PerformanceFrame or a PerformanceNodeFrame classes anywhere other than the docs. Did this not get implemented because it depends on libuv/libuv#1489, or is there something else I am missing?

@sam-github

sam-github Sep 22, 2017

Member

@jasnell I'm not finding this property on the performance object, and I can't find any sign of a PerformanceFrame or a PerformanceNodeFrame classes anywhere other than the docs. Did this not get implemented because it depends on libuv/libuv#1489, or is there something else I am missing?

This comment has been minimized.

@jasnell

jasnell Sep 22, 2017

Member

That should have been removed. I may have forgotten to do so. Yes, the libuv pr needs to land before that can return

@jasnell

jasnell Sep 22, 2017

Member

That should have been removed. I may have forgotten to do so. Yes, the libuv pr needs to land before that can return

This comment has been minimized.

@jasnell

jasnell Sep 22, 2017

Member

That should have been removed. I may have forgotten to do so. Yes, the libuv pr needs to land before that can return

@jasnell

jasnell Sep 22, 2017

Member

That should have been removed. I may have forgotten to do so. Yes, the libuv pr needs to land before that can return

sam-github added a commit to sam-github/node that referenced this pull request Sep 27, 2017

perf_hooks: remove docs for unimplemented API
The node frame (aka loop) timing API did not land, it depends on
libuv/libuv#1489 which is still a WIP.

See: nodejs#14680 (comment)

@sam-github sam-github referenced this pull request Sep 27, 2017

Closed

perf_hooks: remove docs for unimplemented API #15641

0 of 4 tasks complete

jasnell added a commit that referenced this pull request Sep 29, 2017

perf_hooks: remove docs for unimplemented API
The node frame (aka loop) timing API did not land, it depends on
libuv/libuv#1489 which is still a WIP.

See: #14680 (comment)

PR-URL: #15641
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

MylesBorins added a commit that referenced this pull request Sep 29, 2017

perf_hooks: remove docs for unimplemented API
The node frame (aka loop) timing API did not land, it depends on
libuv/libuv#1489 which is still a WIP.

See: #14680 (comment)

PR-URL: #15641
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

addaleax added a commit to addaleax/ayo that referenced this pull request Sep 30, 2017

perf_hooks: remove docs for unimplemented API
The node frame (aka loop) timing API did not land, it depends on
libuv/libuv#1489 which is still a WIP.

See: nodejs/node#14680 (comment)

PR-URL: nodejs/node#15641
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

MylesBorins added a commit that referenced this pull request Oct 3, 2017

perf_hooks: remove docs for unimplemented API
The node frame (aka loop) timing API did not land, it depends on
libuv/libuv#1489 which is still a WIP.

See: #14680 (comment)

PR-URL: #15641
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

MylesBorins added a commit that referenced this pull request Oct 3, 2017

perf_hooks: remove docs for unimplemented API
The node frame (aka loop) timing API did not land, it depends on
libuv/libuv#1489 which is still a WIP.

See: #14680 (comment)

PR-URL: #15641
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

MylesBorins added a commit that referenced this pull request Oct 11, 2017

perf_hooks: remove docs for unimplemented API
The node frame (aka loop) timing API did not land, it depends on
libuv/libuv#1489 which is still a WIP.

See: #14680 (comment)

PR-URL: #15641
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
@gibfahn

This comment has been minimized.

Show comment
Hide comment
@gibfahn

gibfahn Jan 15, 2018

Member

Release team were -1 on landing on v6.x, if you disagree let us know.

Member

gibfahn commented Jan 15, 2018

Release team were -1 on landing on v6.x, if you disagree let us know.

@antonyt antonyt referenced this pull request Jan 23, 2018

Closed

doc: Add doc for performance.clearGC() #18331

2 of 2 tasks complete

gabrielschulhof added a commit to gabrielschulhof/node that referenced this pull request Mar 12, 2018

2017-09-12, Version 8.5.0 (Current)
Notable Changes

* build:
  * Snapshots are now re-enabled in V8
  nodejs#14875

* console:
  * Implement minimal `console.group()`.
  nodejs#14910

* deps:
  * upgrade libuv to 1.14.1
    nodejs#14866
  * update nghttp2 to v1.25.0
    nodejs#14955

* dns:
  * Add `verbatim` option to dns.lookup(). When true, results from the
    DNS resolver are passed on as-is, without the reshuffling that
    Node.js otherwise does that puts IPv4 addresses before IPv6
    addresses.
    nodejs#14731

* fs:
  * add fs.copyFile and fs.copyFileSync which allows for more efficient
    copying of files.
    nodejs#15034

* inspector:
  * Enable async stack traces
    nodejs#13870

* module:
  * Add support for ESM. This is currently behind the
    `--experimental-modules` flag and requires the .mjs extension.
    `node --experimental-modules index.mjs`
    nodejs#14369

* napi:
  * implement promise
    nodejs#14365

* os:
  * Add support for CIDR notation to the output of the
    networkInterfaces() method.
    nodejs#14307

* perf_hooks:
  * An initial implementation of the Performance Timing API for
    Node.js. This is the same Performance Timing API implemented by
    modern browsers with a number of Node.js specific properties. The
    User Timing mark() and measure() APIs are implemented, as is a
    Node.js specific flavor of the Frame Timing for measuring event
    loop duration.
    nodejs#14680

* tls:
  * multiple PFX in createSecureContext
    [#14793](nodejs#14793)

* Added new collaborators:
  * BridgeAR – Ruben Bridgewater

This applies parts of a10856a that are
relevant to N-API.

PR-URL: nodejs#15308

gabrielschulhof added a commit to gabrielschulhof/node that referenced this pull request Mar 15, 2018

2017-09-12, Version 8.5.0 (Current)
Notable Changes

* build:
  * Snapshots are now re-enabled in V8
  nodejs#14875

* console:
  * Implement minimal `console.group()`.
  nodejs#14910

* deps:
  * upgrade libuv to 1.14.1
    nodejs#14866
  * update nghttp2 to v1.25.0
    nodejs#14955

* dns:
  * Add `verbatim` option to dns.lookup(). When true, results from the
    DNS resolver are passed on as-is, without the reshuffling that
    Node.js otherwise does that puts IPv4 addresses before IPv6
    addresses.
    nodejs#14731

* fs:
  * add fs.copyFile and fs.copyFileSync which allows for more efficient
    copying of files.
    nodejs#15034

* inspector:
  * Enable async stack traces
    nodejs#13870

* module:
  * Add support for ESM. This is currently behind the
    `--experimental-modules` flag and requires the .mjs extension.
    `node --experimental-modules index.mjs`
    nodejs#14369

* napi:
  * implement promise
    nodejs#14365

* os:
  * Add support for CIDR notation to the output of the
    networkInterfaces() method.
    nodejs#14307

* perf_hooks:
  * An initial implementation of the Performance Timing API for
    Node.js. This is the same Performance Timing API implemented by
    modern browsers with a number of Node.js specific properties. The
    User Timing mark() and measure() APIs are implemented, as is a
    Node.js specific flavor of the Frame Timing for measuring event
    loop duration.
    nodejs#14680

* tls:
  * multiple PFX in createSecureContext
    [#14793](nodejs#14793)

* Added new collaborators:
  * BridgeAR – Ruben Bridgewater

This applies parts of a10856a that are
relevant to N-API.

PR-URL: nodejs#15308
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment