Repository navigation
perf_hooks: expose performance global #28635
Description
Activity
I'm quite confused, it would be something like
performance.perfMember, whereperfMemberis provided by an abstraction layer ofperf_hookmodule?I'm quite confused, it would be something like
performance.perfMember, whereperfMemberis provided by an abstraction layer ofperf_hookmodule?I think the suggestion is that
perf_hooks.performanceshould be exposed asglobal.performance.In that case won't be difference between using require like:
const { performance } = require('perf_hooks'), and just usingglobalsuch asglobal.performance? A package that behaves like a module and is part ofglobal, feels weird to me (IMO)In that case won't be difference between using require like:
const { performance } = require('perf_hooks'), and just usingglobalsuch asglobal.performance? A package that behaves like a module and is part ofglobal, feels weird to me (IMO)console.log(require('timers').setTimeout === global.setTimeout); // true
Reacted by Juan JoséReacted by Juan Josécan I work on this?
@jasnell any objections here?
Can I?
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.
Reacted by Juan JoséReacted by Juan José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.
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.
Reacted by silverwind, Juan José and Ruben BridgewaterIs there a tracking list of what should have been done to move
perf_hooksmodule out of experimental?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
performanceobject a global, however -- for the same reason I give above.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
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.
- added a commit that references this issue
on May 19, 2020 - added a commit that references this issue
on May 21, 2020 - added 2 commits that reference this issue
on Jun 7, 2020 Fixed by #37970.
Reacted by Ciro Santilli (三西猴) OurBigBook.com sponsor me: cirosantilli.com/sponsor, opinions my own 2020冠状病毒审查 ，2020郝海东 ，2018新疆改造中心，1989六四事件，1999法轮功 ，2019 996.ICU, 2018包子露宪，2015 709大抓捕，2015巴拿马文件 邓家贵，2017低端人口，2008西藏骚乱<script>alert(1)</script>- added a commit that references this issue
on Apr 19, 2025
Browsers export a
performanceglobal, and I think we should too if theperf_hooksmodule is stable enough (and can be lifted from experimental stability) to allow easy usage in isomorphic scripts.