Tracing WebKit made easy

I spent most of the past week doing some performance tuning on the port of WebKit to QNX Neutrino that Crank Software is doing.  There are lots of different tools I could use but nothing beats the System Profiler when you want to get a quick overview of what is going on with your application and its effect on the rest of the system.

Since we’re building WebKit ourselves, I was able to add in a number of user trace events that had specific meaning for the WebKit performance metrics we were looking at.  With a few events, it made repetitive measurements of things like application load time, page load time and network latency a snap to calculate.

Prior to the 6.4.0 release, if you wanted to add in your own custom trace events you had to use the TraceEvent() API.  This API does way more than just insert trace events, it is the swiss army knife of calls to configure and control the entire kernel instrumentation system.  At the end of the day, I was always having to go back to the documentation just to double check the arguments required to push out an event with a string in it:

TraceEvent(_NTO_TRACE_INSERTUSRSTREVENT, <id>, <string>)

Of course if you wanted anything more than a simple string, you had to fiddle with sprintf’s, allocate buffers etc.  A number of times I simply would insert five or six trace events in a row rather than doing all that extra work … which of course meant havin log files cluttered with extra events I eventually needed to filter out to see what I wanted.

With 6.4.0 a whole slew of trace_* functions were added into the <sys/trace.h> header.  Now instead of having to remember the specific define for the TraceEvent() call, I can just do:

 trace_logf(<id>, <printf style format string>);

That is way easier and far more convenient … makes tracing almost as much fun as using my ShamWow

Unfortunately the functions aren’t documented yet, but they were modelled using the same style as the slog_* functions, and you have to be carefull about their use within interrupt handlers but things like the trace_here() function can offer interesting insight using the other optimization tools.

… and in case you were wondering about the WebKit optimization results, they are looking good.  We’ve eliminated most of the superfluous work that hit embedded systems (especially non-x86 targets) harder than desktops and hope to be making a very usable GF based version available soon!

Happy Tracing!



5 comments so far

  1. Paul Leroux on

    The blog… it’s… alive!!! Welcome back, Thomas!

    And no matter what you say, your ShamWow ain’t got nothin’ on my LCD Shovel 2007:

  2. sendreceivereply on

    LCD shovel eh … intriguing, but is it “Made in Germany!”?

    Blog’s never die, they just become vintage.

  3. Mario on

    A classic:

    Works without batteries!

  4. […] search results Posted March 20, 2009 Filed under: QNX | In the last few posts [1][2][3] I’ve been talking about how the developers at Crank have been finding and addressing some of […]

  5. Steve Reid on

    Seeing as you’ve outed the trace_* functions, I’ve written some docs for them. They’ll be in the Neutrino Library Reference in the next release.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: