Node: perf_hooks: expose `performance` global

[silverwind]

Browsers export a performance global, and I think we should too if the perf_hooks module is stable enough (and can be lifted from experimental stability) to allow easy usage in isomorphic scripts.

[juanarbol]

I'm quite confused, it would be something like performance.perfMember, where perfMember is provided by an abstraction layer of perf_hook module?

[Trott]

I'm quite confused, it would be something like performance.perfMember, where perfMember is provided by an abstraction layer of perf_hook module?

I think the suggestion is that perf_hooks.performance should be exposed as global.performance.

[juanarbol]

In that case won't be difference between using require like: const { performance } = require('perf_hooks'), and just using global such as global.performance? A package that behaves like a module and is part of global, feels weird to me (IMO)

[Trott]

In that case won't be difference between using require like: const { performance } = require('perf_hooks'), and just using global such as global.performance? A package that behaves like a module and is part of global, feels weird to me (IMO)

console.log(require('timers').setTimeout === global.setTimeout); // true

[juanarbol]

can I work on this?

[silverwind]

@jasnell any objections here?

[juanarbol]

Can I?

[Trott]

Can I?

Yes. Not that you need my permission or authority or anything, but if it makes you feel OK about forging ahead: Go for it. No guarantees that it will be accepted or that someone else isn't already working on it (although they probably aren't), but if this is something you'd like to see in Node.js core, you should totally put together a pull request for it.

[juanarbol]

Done at #29432 using perf_hooks module

[jasnell]

Yikes, I just spotted this. There's a reason we don't expose it as a global... Specifically, doing so is semver-major and the current implementation is not fully compatible with the browser version.

[joyeecheung]

IIRC, the convention is exposing a Web API to global when it is no longer experimental. I think at least we should take a look into the criteria for moving performance out of experimental status first.

[legendecas]

Is there a tracking list of what should have been done to move perf_hooks module out of experimental?

[jasnell]

I think it's time that we could. The module has been stable for a while now. There's really no checklist necessary in this case. It has tests, it's being used, so I think we could just open a PR making it stable. I still do not believe we should make the performance object a global, however -- for the same reason I give above.

[gireeshpunathil]

fwiw, here is one or more criteria that can be reasonably checked against, for experimental exit:

• [ ] API interfaces (functions / CLI) are evolved
• [ ] user land modules are built on top
• [ ] evidence of usage in production
• [ ] test coverage in CI
• [ ] No / containable flaky tests

[joyeecheung]

I think it would be good to at least import https://github.com/web-platform-tests/wpt/tree/master/performance-timeline and figure out the difference between the Web before moving this to global, considering people could very well use the same code as how they would use it on the Web and run into differences (which could either be bugs or just wontfix). It would also be good to figure out the subset of performance timeline we want to implement and what we explicitly won't.