Skip to content

Deprecating the process._startProfilerIdleNotifier & process._stopProfilerIdleNotifier methods #19009

Description

@JacksonTian

When I browse the source code of src/node.cc, I found _startProfilerIdleNotifier & _stopProfilerIdleNotifier methods. These methods never be documented and haven't any test cases in test/*.

I am proposing that we can mark the two methods as deprecated and remove later.

In user land, v8-profiler can do things better.

If no against for this proposal, I will start the work.

CC @nodejs/collaborators

Activity

  1. changed the title [-]remove[/-] [+]remove the process._startProfilerIdleNotifier & process._stopProfilerIdleNotifier methods[/+] on Feb 26, 2018
  2. changed the title [-]remove the process._startProfilerIdleNotifier & process._stopProfilerIdleNotifier methods[/-] [+]Deprecate the process._startProfilerIdleNotifier & process._stopProfilerIdleNotifier methods[/+] on Feb 26, 2018
  3. changed the title [-]Deprecate the process._startProfilerIdleNotifier & process._stopProfilerIdleNotifier methods[/-] [+]Deprecating the process._startProfilerIdleNotifier & process._stopProfilerIdleNotifier methods[/+] on Feb 26, 2018
  4. bnoordhuis commented on Feb 26, 2018

    @bnoordhuis
    Member

    I know I added them but I'll be damned if I remember why. I'm good with removing them.

  5. mcollina commented on Feb 27, 2018

    @mcollina
    SponsorMember

    👍 to remove or runtime-deprecate them.

  6. benjamingr commented on Feb 27, 2018

    @benjamingr
    Member

    Anyone using these methods in userland?

  7. ofrobots commented on Jul 6, 2018

    @ofrobots
    Contributor

    Just found this issue while trying to understand why Node doesn't notify the VM for idle phases by default.

    I don't know the motivation that @bnoordhuis had originally. My motivation is from a profiler perspective. A profiler (e.g. Chrome DevTools) should be able to distinguish JS execution vs. native execute vs. idle time. Currently, when no JS is executing, the profiler has no idea if Node was spending time in C++ or was really idle.

    Apart from the the diagnostic use-case, I think the VM might also be able to get a better idea of process load based on how busy the host (Node) seems to be, and might be able to take advantage of this in tweaking GC and background compilation heuristics. This is not profiling specific.

    IOW, I think we should

    1. Perform idle notifications by default. I think the current mechanism (uv_prepare_t, uv_check_t) might do a few too many notifications (once per loop iteration). I think this can be improved.
    2. If we do that, we do not need to expose these functions to JavaScript. I'm +1 on deprecating and removing these, if we do the previous bullet (I'd be happy to go implement that).

    WDYT? Any concerns/objections?

  8. joyeecheung commented on Jul 8, 2018

    @joyeecheung
    Member

    @ofrobots (This may not be helpful but FWIW) I think I've seen somewhere in the comments that the idle notifications in core were removed because they "did not work well". But those notes were ancient and it's probably not a bad time to revisit this and integrate the core better with the VM.

  9. ofrobots commented on Jul 9, 2018

    @ofrobots
    Contributor

    @joyeecheung thanks! if you have pointers to some of these discussions, those would be very useful for me. Perhaps you were thinking of requestIdleCallback (#2543) – which is something very different?

  10. joyeecheung commented on Jul 10, 2018

    @joyeecheung
    Member

    @ofrobots Did some archeology and I am pretty sure I was talking about d607d85 although it seems specific to regulating GC

  11. Yogu commented on Nov 16, 2018

    @Yogu

    @ofrobots I don't know any node internals, but I'm 100% with you on enabling these by default (if there are no significant performance problems). And thanks a lot for this PR where you fixed it in a project - I shamelessly copied it into my project to get idle times working. ❤️

  12. Trott commented on Apr 22, 2020

    @Trott
    Member

    Looks like these are now in src/node_process_methods.cc.

    What's the status of this?

    1. Perform idle notifications by default. I think the current mechanism (uv_prepare_t, uv_check_t) might do a few too many notifications (once per loop iteration). I think this can be improved.
    2. If we do that, we do not need to expose these functions to JavaScript. I'm +1 on deprecating and removing these, if we do the previous bullet (I'd be happy to go implement that).

    Did the first bullet point ever happen? If not, is there someone motivated to implement it? I don't get the impression that either @JacksonTian or @ofrobots are terribly active on the project these days, but I'd be thrilled to see them or anyone else jump in on this to get it across the finish line.

  13. bnoordhuis commented on Apr 22, 2020

    @bnoordhuis
    Member

    I remember what my motivation for adding those methods was. It's to stop the V8 profiler from counting time spent sleeping in epoll_wait(2) or kevent(2) as CPU (i.e., running) time.

    We handle that in libuv now so in that respect the start/stop methods aren't necessary anymore:

    uv_loop_configure(uv_default_loop(), UV_LOOP_BLOCK_SIGNAL, SIGPROF);

    There's probably still value in post-processing tools knowing when node is sleeping but prepare/check handles are too coarse for that: I/O callbacks run in between and, as a result, are counted as idle time.

  14. Trott commented on Apr 26, 2020

    @Trott
    Member

    I remember what my motivation for adding those methods was. It's to stop the V8 profiler from counting time spent sleeping in epoll_wait(2) or kevent(2) as CPU (i.e., running) time.

    We handle that in libuv now so in that respect the start/stop methods aren't necessary anymore:

    uv_loop_configure(uv_default_loop(), UV_LOOP_BLOCK_SIGNAL, SIGPROF);

    There's probably still value in post-processing tools knowing when node is sleeping but prepare/check handles are too coarse for that: I/O callbacks run in between and, as a result, are counted as idle time.

    I'm sorry, but I'm not sure I fully understand. Does this mean that this issue can be closed? Or does it mean that it can be closed after we do some work in core to rely on libuv's handling of this?

  15. bnoordhuis commented on Apr 27, 2020

    @bnoordhuis
    Member

    There's a bit of scope creep going on in this issue. Let's start with @JacksonTian's proposal to deprecate the methods.

    I think that's a fine thing to do - they're not necessary and I shouldn't have added them. 6820054...f649626 is the relevant changeset; I added them because I could, not because I should.

    This issue should stay open until that change is made.

    Next is @ofrobots's sugggestion: perform idle notifications by default. I also think that's a fine thing to do but it's a separate issue. Let's open a new issue for that.

  16. added a commit that references this issue on Apr 29, 2020
  17. addaleax commented on Apr 29, 2020

    @addaleax
    Member

    If we decide to perform idle notifications by default, then I would just indefinitely leave these methods as no-op stubs, which renders deprecating unnecessary. I’ve opened #33138 to implement that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions