CPU Profiling implementation for WebDriver

[elfo...@gmail.com]

Hi!

I'm interested in implementing the CPU Profile API for WebDriver (well the chrome version of it).

I asked guidance from klm@google.com and stgao@chromium.org, since they implemented the perf logging and the heapSnapshot. And they gave me the first indication about where to look.

So I debugged the DevTools protocol and analyzed protocol.json. It seems that the message exchange is fairly simple:

console.profile or clicking on the record will trigger over websockets: -> {"method":"Profiler.start","id":xxxx}

console.profileEnd or clicliend EndRecrod will trigger over websokets: -> {"method":"Profiler.stop","id":28}

And the return payload will be a JSON object like:  "result": {    "profile": {      "head": { ... }}} Given this format exchange, I think the implementation it shouldn't be hard to do....

Moreover I saw the code that stgao implemented for the takeHeapSnapshot and basically he created a special Execute function on the window_commands.cc, that delegates into WebView new function, and a special module to do the heavy lifting, so the usage is fairly simple: https://code.google.com/p/chromedriver/issues/detail?id=519

Given that this is probably a non standard WebDriver feature I think I should follow the same pattern and creating another Executor function on window_commands.cc that relies on the web_view and has a class to manage the results.

Does this seems like the right direction to start coding this feature?

Do you guys need more details?

Can anyone throw more light to this or some other details I may be missing?

Thanks!

[Shuotao Gao]

On Wed, May 7, 2014 at 7:11 PM, <elfo...@gmail.com> wrote:

Hi!

I'm interested in implementing the CPU Profile API for WebDriver (well the chrome version of it).

I asked guidance from klm@google.com and stgao@chromium.org, since they implemented the perf logging and the heapSnapshot. And they gave me the first indication about where to look.

So I debugged the DevTools protocol and analyzed protocol.json. It seems that the message exchange is fairly simple:

console.profile or clicking on the record will trigger over websockets: -> {"method":"Profiler.start","id":xxxx}

console.profileEnd or clicliend EndRecrod will trigger over websokets: -> {"method":"Profiler.stop","id":28}

And the return payload will be a JSON object like:  "result": {    "profile": {      "head": { ... }}} Given this format exchange, I think the implementation it shouldn't be hard to do....

I will leave this part to devtools folks. 

Moreover I saw the code that stgao implemented for the takeHeapSnapshot and basically he created a special Execute function on the window_commands.cc, that delegates into WebView new function, and a special module to do the heavy lifting, so the usage is fairly simple: https://code.google.com/p/chromedriver/issues/detail?id=519

Given that this is probably a non standard WebDriver feature I think I should follow the same pattern and creating another Executor function on window_commands.cc that relies on the web_view and has a class to manage the results. 

For this part on ChromeDriver side, I will reply you in a separate email.

[Yury Semikhatsky]

On Thu, May 8, 2014 at 6:11 AM, <elfo...@gmail.com> wrote:

Hi!

I'm interested in implementing the CPU Profile API for WebDriver (well the chrome version of it).

I asked guidance from klm@google.com and stgao@chromium.org, since they implemented the perf logging and the heapSnapshot. And they gave me the first indication about where to look.

So I debugged the DevTools protocol and analyzed protocol.json. It seems that the message exchange is fairly simple:

console.profile or clicking on the record will trigger over websockets: -> {"method":"Profiler.start","id":xxxx}

console.profileEnd or clicliend EndRecrod will trigger over websokets: -> {"method":"Profiler.stop","id":28}

No, this has changed some time ago. Now console.profile will trigger Profiler.consoleProfileStarted event and console.profileEnd will result in Profiler.consoleProfileFinished. These events will only be sent for console initiated profiles and Profiler.start/stop commands will not trigger them. This is how we differentiate between console started profiles and profiles started by devtools front-end. Also bear in mind that console.profile/profileEnd won't work unless Profiler agent is enabled via Profiler.enable command.

 

And the return payload will be a JSON object like:  "result": {    "profile": {      "head": { ... }}} Given this format exchange, I think the implementation it shouldn't be hard to do....

This is the format that we use at the moment but it may change in the future as Profiler domain is not published yet. The payload will also contain arrays of samples in the form of call stach + timestamp (see https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/devtools/protocol.json&q=protocol.json&sq=package:chromium&type=cs&l=3357)

 

Moreover I saw the code that stgao implemented for the takeHeapSnapshot and basically he created a special Execute function on the window_commands.cc, that delegates into WebView new function, and a special module to do the heavy lifting, so the usage is fairly simple: https://code.google.com/p/chromedriver/issues/detail?id=519

Given that this is probably a non standard WebDriver feature I think I should follow the same pattern and creating another Executor function on window_commands.cc that relies on the web_view and has a class to manage the results.

Does this seems like the right direction to start coding this feature?

Do you guys need more details?

Can anyone throw more light to this or some other details I may be missing?

Thanks!

--
You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-chrome-developer-tools/ae0506ef-dd44-48e5-b56d-b765747d6f50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Diego Ferreiro]

Thanks for the quick response.

So given that I will be talking directly to the DevTools API through ChromeDriver, I guess I should still use Profile.start

Also thanks for the hint for the Profile.enable

Is there any reason why the API is not yet public? because its been a while since you guys have this feature on chrome. 

How likely is a change in the payload protocol? 

Because IMHO, even if for now is not officially public, we could still add the feature on the ChromeDriver side, assuming that the client commands are trivial to change, and only the consumer of the payload is the one that has to adapt to the protocol change. So even if no official support, people could still use it at its own risk.

I will try to make it work (I really want this metric for the framework I'm building), and then you guys evaluate what to do with the code.

Any other hint or help will be welcome! :)

Thanks!

To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-developer-tools+unsub...@googlegroups.com.