- Date: 2016-06-01
- YouTube: http://www.youtube.com/watch?v=tNxYDvQ1kT8
- @joshgav
- @mhdawson
- @matthewloring
- @ofrobots
- @paulirish
- @pavelfeldman
- @caseq
- @jasonlaster
- @pmuellr
- @fmeawad
- several more via YouTube
- TRACE_EVENT - Google's plans and how Node can build on them (@ofrobots)
- Trace module - @joshgav's proposal - why and what.
- [#50], [joshgav/node-trace]
- Chrome Debugging Protocol and v8_inspector (@ofrobots, Google)
- [nodejs/node#6792], [nodejs/node#7072]
- What it brings to Node and the community now and in the future.
- How can the Diagnostics WG utilize it?
- AsyncWrap [deferred]
- Expanding scope of this WG [deferred]
- Return to monthly cadence - first Wednesday of each month at 12pm US Pacific (immediately before CTC meeting). Next meeting will be July 6.
In Chromium, the Trace Event trace system is implemented through a Tracing Controller. @fmeawad is porting this system into V8/D8. @ofrobots and @matthewloring plan to adjust and integrate with Node afterwards.
In this Tracing Controller, traces are not streamed, they are collected in memory and dumped on request. It would be up to Node to determine how to flush, stream, etc. in Node.
chrome://tracing is intended for platform developers while “Timeline” view in Chrome DevTools is intended for web/app developers. Data source is the same but filtered differently for each tool.
Currently structural tracing is used, but work is in progress to make sampling tracing more efficient/performant and shift to sampling for most uses. See this video for background on structural vs. sampling tracing.
-
@pavelfeldman: Not exactly. We should use trace points (TRACE_EVENT) for C++ instrumentation of the engine and modules, but we should run sampler at all times for complete JS coverage (both engine and user land).
We can already collect JS samples in the tracing format so that the whole profile was a single payload, but we are not satisfied with the memory footprint it generates. So we are working on a revised format that would scale. In the meanwhile, we simply start both Tracing and JS profiler (sampler) and merge reports on the client side.
CDP allows configuration of tracing through the Tracing domain: https://chromedevtools.github.io/debugger-protocol-viewer/tot/Tracing/
Google recommends we use the same tracing components but configure appropriately for Node.
Trace output can be processed and visualized by other tools too. Google is evaluating trace output format, considering binary format perhaps based on protobuf. Currently format is agreed upon by Chromium teams and documented here: https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/preview
Chromium’s tracing system and implementation could be used for Node core as well as native and JS modules.
In V8, console.time and console.timeEnd mark a timestamp and send a trace event. Would need a Node-specific JS implementation using Node-appropriate semantics, possibly in console. See https://chromium.googlesource.com/chromium/src/+/lkcr/third_party/WebKit/Source/core/inspector/ThreadDebugger.cpp for example.
4μs per call when tracing is on (0 when off) with Chromium Tracing Controller. Categories which are disabled are off (no penalty).
Original V8 Debugging Protocol doesn’t support object mirrors efficiently (can’t get props without values). CDP allows V8 to drop support for old protocol, especially the mirrors.
Benefits: It’s more efficient. Domains.
Anyone can add domains, Node could identify a canonical subset of the protocol to be supported.
Google/V8 have only been adding to CDP, not changing existing messages.
CDT is reference impl of protocol. In GitHub (CDT repo) there’s an SDK layer that CDT uses to connect to the protocol.
Next meeting: Wednesday 7/6, 12pm US Pacific.
For discussions, Josh will start and continue threads in nodejs/tracing-wg.
These topics were deferred to GitHub and/or a later meeting:
- AsyncWrap (@trevnorris)
- [#29], [nodejs/node-eps#18]
- Expanding scope of this workgroup as Diagnostics WG (#46, #47)