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

Already on GitHub? Sign in to your account

Flame chart #41

paulmillr opened this Issue Nov 27, 2013 · 14 comments


None yet
3 participants

Chrome has flame charts which are awesome for debugging

screen shot 2013-11-27 at 18 25 49

Any chance this will be in webkit-agent too?


c4milo commented Dec 11, 2013

Unfortunately not in the near future, unless somebody else contributes it.

chiubaka commented Sep 7, 2014

@c4milo I'm really hurting for this functionality somewhere. I'm making a massively multiplayer online game and the server is currently in node.js. We really need to understand some of the timing behind what's being called.

It sounds like this isn't a priority for this repository, but if you were point in me the right direction to get started I'm hurting badly enough for this functionality that I would consider implementing it myself and contributing it back.


c4milo commented Sep 7, 2014

Hey Daniel, I'm sorry to hear that you are having problems due to the lack of this feature. I would suggest to start studying how node-webkit-agent is implemented, then finding out where Chrome Devtools gets the data from, and whether or not it is part of the inspector protocol.


c4milo commented Sep 7, 2014

I'm going to try something to see if it is just a simple thing.


c4milo commented Sep 7, 2014

It seems it takes the same cpu profiling information sent by v8. https://github.com/yoavweiss/Blink/blob/master/Source/devtools/front_end/profiler/CPUProfileFlameChart.js#L41

Assuming the above is correct, it will be a matter of testing node-webkit-agent with the latest stable version of devtools frontend, shipped with Chrome. If it doesn't work then we need to look into what changed in the internal devtools protocol and make the correspondent adjustments so that the frontend can understand what node-webkit-agent is sending it.

chiubaka commented Sep 7, 2014

Wow, thanks for the fast response, @c4milo, and thanks for taking a look into this for me. Eager to learn what you find! In the meantime, I've played around more with other possible ways to get flamechart timelines for Node.js and have found nothing that works. Extending node-webkit-agent seems to be the most tangible option, so I'm going to try to start understanding how all of this works!


c4milo commented Sep 7, 2014

you can also get a recent version of devtools frontend by cloning
git clone https://chromium.googlesource.com/chromium/blink it is going to take a while.

More info: https://developer.chrome.com/devtools/docs/contributing

chiubaka commented Sep 8, 2014

@c4milo were you planning on taking a closer look at this, or should I start getting ramped up in the necessary code bases? Just wanted to clarify so I don't start on something that you're planning on working on.

Thanks for your help!


c4milo commented Sep 8, 2014

@chiubaka I sandboxed 2 hours but I couldn't finish it. I'm unfamiliar with the new Chrome codebase and it is going to take some time to figure out how to extract devtools frontend from there. I will pass it on to you from here.

My ongoing notes for extracting devtools:

Extracting devtools front-end from Blink

  1. Get the chromium commit hash, branch_commit column, used for the latest stable version of Chrome from: http://omahaproxy.appspot.com
  2. Get the chromium and blink source following http://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/depot_tools_tutorial.html (fetch blink)
  3. Checkout commit branch_commit identified in step 1
  4. Either figure out how to individually compile devtools frontend so that InspectorBackendCommands.js is generated or compile the whole chromium codebase. This file is usually generated based on the protocol.json file inside devtools. InspectorBackendCommands.js is the RPC layer for devtools front-end to communicate with the node agent or a Chromium browser.
  5. Checkout gh-pages branch in node-webkit-agent
  6. Following the same convention I have in gh-pages branch, add yet one more devtools front-end version, copy the devtools frontend files from blink, including the generated InspectorBackendCommands.js


Thanks for the resources, @c4milo. I've been playing around with this yesterday and today. So far I think I've gotten the newest version of Blink, I've found the devtools front end files, and I've figured out how to generate InspectorBackendCommands.js.

I guess if my understanding is correct, then there are kind of 2 cases:

  1. I get lucky and the protocol hasn't changed that much so the new version of the devtools front end still understands what node-webkit-agent is sending it.
  2. I don't get lucky, and I need to figure out how to get node-webkit-agent to send data that conforms to the updated protocol.

Right now I'm struggling with two main things:

  1. In the version of the devtools front end that you used (~26), it looks like a remote host could be specified using GET variables (e.g. inspector.html?host=localhost:9999&page=0). In version 37 (the newest stable version, which does have flame charts), this doesn't seem to work. So far I haven't been able to figure out how to get the new front end to understand its debugging target.
  2. It seems like the protocol has probably changed by a reasonable amount. Here's a diff of the InspectorBackendCommand.js files for the two different versions: https://gist.github.com/chiubaka/65cd975539ab9cca74a3. Can you provide with any advice for how to get started reconciling these differences?

c4milo commented Sep 12, 2014

You are on the right path @chiubaka. In addition to the devtools rpc protocol, v8's heap and cpu profiling serialization format could have changed too. That's another thing to consider.

To answer your questions:

  1. Unfortunately, I don't have a good answer for this question. We will have to get into #chrome-devtools at freenode and ask about this.
  2. The first thing is to get the frontend connecting to the node agent. Once that's done, the agent will start to print to stdout unimplemented rpc methods. I would usually see which methods make sense to implement for node and dig in more the messaging by sniffing a normal devtools session in any chrome browser. I believe newest versions of devtools allows you to enable showing the messaging by setting a debug variable, unlike the old days. But, we will have to find out how to do that too. :/

c4milo commented Sep 12, 2014

@chiubaka I asked Paul Irish about the host parameter and this was his answer:

So, it will probably be something like: http://c4milo.github.io/node-webkit-agent/26.0.1410.65/inspector.html#http://localhost:9999

@c4milo Thanks for jumping on the IRC to get that answered for me! I tried a format like what you suggested and that didn't work.

I also tried something like: http://c4milo.github.io/node-webkit-agent/26.0.1410.65/inspector.html#localhost:9999

I just grepped through the new front end code and found a reference to a websocket connection in common/WebInspector.js:

_createConnection: function()

    var workerId = WebInspector.queryParam("dedicatedWorkerId");
    if (workerId) {
        this._connectionEstablished(new WebInspector.ExternalWorkerConnection(workerId));

    if (WebInspector.queryParam("ws")) {
        var ws = "ws://" + WebInspector.queryParam("ws");
        InspectorBackendClass.WebSocketConnection.Create(ws, this._connectionEstablished.bind(this));

    if (!InspectorFrontendHost.isHostedMode()) {
        this._connectionEstablished(new InspectorBackendClass.MainConnection());

    this._connectionEstablished(new InspectorBackendClass.StubConnection());

Based on this, I believe that I have determined that the correct way to specify a websocket target to connect to is by adding the "ws" query parameter like so: http://c4milo.github.io/node-webkit-agent/26.0.1410.65/inspector.html?ws=localhost:9999

Doing this, it looks like I've gotten the front end connected to the node agent. In fact, in the node agent's console I am starting to see some not implemented messages like so:


Seems like none of the functionality on the front end works at the moment. Can you provide any additional advice on how to begin attacking these not implemented messages? Are these commands that are being sent by the front end that node-webkit-agent doesn't understand, or the other way around?


c4milo commented Sep 15, 2014

Those three red messages are irrelevant for profiling. I would say, start a profiling session in any website, using the regular devtools that comes with your browser. Then, sniff the WS messaging of that session and make sure node-webkit-agent behaves the same.

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