trace_event.h tracking issue

[Qard]

This is a tracking issue for trace_event.h integration. If I've missed anything, please add it.

• Overview from @ofrobots: Tracing WG Meeting 2015-09-25 #21 (comment)
• In-depth design rationale from @natduca: tracing working group node#671 (comment)
• V8 change list: https://codereview.chromium.org/988893003/
• Chromium parts: trace_log.h, trace_log.cc, trace_buffer.h, trace_buffer.cc

TODO:

• Add trace_event.h files to node, or wait for V8 release with it?
• Create node equivalent to trace_log and trace_buffer in Chromium
  • Need a thread to consume trace data
  • Create JS interface to allow custom storage methods. (Use C++ Streams?)
• Use TRACE_EVENT_BEGIN0, TRACE_EVENT_END0, TRACE_EVENT_ASYNC_BEGIN0, TRACE_EVENT_ASYNC_END0 macros in node codebase (AsyncWrap might be a good place to start)

[bnoordhuis]

Add trace_event.h files to node, or wait for V8 release with it?

We can add it now if there is a good reason to.

Create node equivalent to trace_log and trace_buffer in Chromium

It would be nice if there was a common library that we could use without pulling in chromium base as a dependency. It's big and painful to build outside the chromium tree.

/cc @ofrobots

Create JS interface to allow custom storage methods. (Use C++ Streams?)

I imagine you'd start with a (public) C++ API, that the JS API ends up calling. The API itself should probably be callback-based, where node.js calls the callback with the raw trace data.

TBD if callbacks are made on the main thread. That's mandatory for the JS API but not for the C++ API and would be a performance drag.

Apropos C++ streams, that seems like a bad fit, never mind that they're not API-stable.

[Qard]

The callbacks thing is why I was wondering about C++ streams. It might be possible to get decent performance just writing it to a file or the network directly in C++, rather than constantly doing the hop to JS. I don't know too much about the stability of C++ streams, it was just a thought.

As for the Chromium bits, it probably makes the most sense to just pull the trace_log and trace_buffer bits out into its own small project that we can dump in the deps folder. @fmeawad

[ofrobots]

It would be nice if there was a common library that we could use without pulling in chromium base as a dependency. It's big and painful to build outside the chromium tree.

My feeling is that it would simpler to copy (and fork) trace_log and trace_buffer files from Chromium. There is a big dependency on chromium base in the file currently and extracting it out to a library would require extricating those dependencies anyway. I personally don't think it is worth the effort required to share these bits between Node.js and Chromium.

[lucamaraschi]

As discussed during the last WG (initiated by @yunong) we should start defining what the expected overall behaviour is by the "consumers" point of view (developer, ops, ...) and use it as the baseline for the implementation. I created a new issue #31 to initiate and track the discussion.

[ofrobots]

FYI, the trace-event CL has since landed into V8 4.9. If anyone wants to play with this, I have Node.js + V8 4.9 branch here: https://github.com/ofrobots/node/tree/vee-eight-4.9.

[ofrobots]

Note that @matthewloring, @kjin and @misterpoe have been working on prototyping TraceEvent for Node on this branch here: https://github.com/matthewloring/node/commits/tracing. This is dependent on V8 5.4. We can open this is as a PR after V8 5.4 lands. Collaboration would be most welcome!

[joshgav]

I'll try to take a look soon, thanks for the update @ofrobots!

/cc @digitalinfinity

[joshgav]

#53 is discussion of integration strategies for this, perhaps we should merge threads.

[joshgav]

conversation continues now in #84