PerformanceNodeTiming of perf_hooks

[theanarkh]

Version

main branch

Platform

No response

Subsystem

perf_hooks

What steps will reproduce the bug?

const { performance } = require('perf_hooks');
console.log(performance.nodeTiming)

How often does it reproduce? Is there a required condition?

always.

What is the expected behavior?

v8Start and nodeStart should be greater than 0 ?

What do you see instead?

nodeStart: -75.49576783180237,
v8Start: -34.36598587036133,
bootstrapComplete: 39.0672550201416,
environment: 0,
loopStart: -1,
loopExit: -1,

Additional information

I am not sure if it is a bug. I think the issue is made by this PR. I just wonder if the user will be a little confused ?
cc @legendecas

[legendecas]

I can confirm the issue is introduced in #43781. The problem is that we are exposing timing entries that are earlier than creating environments. These entries are available in the worker threads too.

As these timing entries are relative to the performance.timeOrigin, we may document that these timing entries that are earlier than the creation of environments can be negative values. However, entries like performanceNodeTiming.loopExit are already documented and if the milestone is not reached yet, the value can be -1. This could be confusing too.

As an alternative, we may revert #43781.

[theanarkh]

If it is expected currently I think we can explain this in the documentation, or i can submit a PR.

[jasnell]

oy, yeah, these should definitely not be negative values. I'd consider this a breaking bug. Either #43781 should be reverted or timeOrigin needs to be set sooner.

[legendecas]

These entries are available in the worker threads too. To avoid observing negative values in the workers, the timeOrigin value in the workers should also be set to the per-process's one, which basically invalidates #43781. Sounds like we should revert #43781.