Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Meetings: Add notes from 2016-06-01 meeting. #54

Merged
merged 1 commit into from Jun 9, 2016

Conversation

joshgav
Copy link
Contributor

@joshgav joshgav commented Jun 2, 2016

Please check for technical and editorial accuracy. Thanks!

Closes #49.

/cc @mhdawson @matthewloring @ofrobots @paulirish @pavelfeldman @caseq @jasonLaster @pmuellr @fmeawad @auchenberg


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.

Instead of “structural tracing” through explicit trace points in code, Google prefers sampling all code. Although slightly less exact on timings this provides more thorough perspective of operations. However, Google hasn’t yet integrated this sampling-based tracing into the default trace configuration.

This comment was marked as off-topic.

This comment was marked as off-topic.

This comment was marked as off-topic.

@mhdawson
Copy link
Member

mhdawson commented Jun 3, 2016

Subject to the suggested changes already made ltgm.


### Tracing

In Chromium, the Trace Event trace system is implemented through a Tracing Controller. @ofrobots and @matthewloring are working on porting this implementation to V8/D8.

This comment was marked as off-topic.

This comment was marked as off-topic.

@joshgav joshgav force-pushed the june-meeting-notes branch 2 times, most recently from d5dfdcc to 04f408e Compare June 3, 2016 16:35
@joshgav
Copy link
Contributor Author

joshgav commented Jun 3, 2016

Updated, PTAL.

@pavelfeldman
Copy link

it sounded like explicit trace points are the current solution, vision and WIP is to move to sampling

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.

@joshgav
Copy link
Contributor Author

joshgav commented Jun 7, 2016

Added Pavel's comment into the notes directly (used a bullet to indent it).

Good to merge?

@joshgav joshgav merged commit dcf171d into nodejs:master Jun 9, 2016
@joshgav joshgav deleted the june-meeting-notes branch August 9, 2016 19:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants