

WebKit gets a new JavaScript profiler courtesy of 280 North (YC W08) - boucher
http://www.alertdebugging.com/2009/04/29/building-a-better-javascript-profiler-with-webkit/

======
jimbokun
Add a "displayName" property to anonymous Javascript functions, then hack the
WebKit debugger to show that in the profiler and debugger. Simple, yet
brilliant.

There's a lesson here in seeing a problem and solving it instead of
complaining about it. I had heard recently about the problem with FireBug (for
example) not having a name to show for anonymous functions, but I considered
it an annoyance to be coped with, rather than a bug to fix.

Also a big win for open source. This process is not possible with IE.

~~~
briansmith
> This process is not possible with IE.

It seems like the IE developers already implemented a trick similar to this
last year: [http://blogs.msdn.com/ie/archive/2008/09/11/introducing-
the-...](http://blogs.msdn.com/ie/archive/2008/09/11/introducing-the-
ie8-developer-tools-jscript-profiler.aspx). For all we know, this WebKit
improvement is inspired by the IE8 profiler. Accordingly, this is a bad case
to use as an example of the alleged benefits of open source over closed source
software since the closed source implementation came first and costs no more
than the open source version.

~~~
ellyagg
Actually, it's not really the specific enhancement that makes it a good
example of the power of open source, but the fact that this is possible at
all. It's not as if there aren't plenty of other features that could be added
using this same process that IE _doesn't_ already have.

------
bdash
The title here is completely inaccurate. Francisco Tolmasky fixed a few bugs
in WebKit's existing profiler, he did not contribute "a new JavaScript
profiler". Many kudos to him for taking the time to fix these issues, but lets
keep things in perspective.

~~~
boucher
Well, I certainly don't want to argue about semantics, but I don't think the
title is "completely inaccurate". The code did not work at all before. It
almost always reported incorrect information. You can consider those bug fixes
if you like.

Additionally, the "heavy" mode was in fact rewritten (and moved from C++ to
JS). The old one wasn't computing any information that was useful.

~~~
bdash
We clearly have very different understandings of the term "at all".

The "heavy" view in the profiler reported incorrect information when recursive
function calls were involved. The default view (top-down) of the profiler
worked fine, and the heavy view worked correctly when recursion was not
involved. The core of the profiler, where the real work is done and the data
is actually collected, also functioned correctly.

Rewriting the display-related code for the heavy view in JavaScript,
addressing the bug in the process, is a definite improvement and it's great to
see third-party developers contributing to the improvement of WebKit's tools.
That said, I fail to see how you can refer to this as contributing a new
profiler while keeping a straight face.

~~~
tolmasky
I hate to have to step in here, but I feel that I should now. The entire
purpose of this blog post was to show how cool the WebKit profiler is,
highlighting some of its new features that we all worked on together and at
the same time teaching people how to better use a tool they probably weren't
familiar with. However, the highest rated discussion here on news.yc is now
quibbling over who deserves credit for what. The worst part is that no one
seems to be arguing that the post itself was unfair, its simply the title of
this particular News YC posting that is of such great concern.

If its that important to "set the record straight", then I have to say that
the heavy view was indeed completely broken prior to this change. The heavy
view used to completely miscalculate _all_ child nodes, adding up there
corresponding individual times instead of how much time the root node used.
This is completely opposite to both the way gprof works as well as Shark. On
top of this, as you mentioned, recursive times were counted several times
over, never reporting them correctly and often resulting in profiling times of
over 1000%. This is not a trivial matter since most of the major javascript
libraries contain recursion or call cycles of some sort. The end result is
that the heavy view could not be trusted at all when measuring a script's
runtime. This is important because the heavy view is what is closest to
Firebug's current behavior, so it was not feasible for someone to make the
switch from using Firebug to WebKit before this point since they couldn't ask
trivial questions like "which function is taking the longest" and expect a
correct answer. Thus, the logic for this feature was completely rewritten and
behaves 100% differently than before. True, most of it was done in JavaScript
instead of C++, but it wasn't "simply display code". We actually investigated
the implementations in gprof and asked our buddies over on the Shark team what
the correct behavior should be and coded it up. The reason we chose to do this
almost entirely in JavaScript instead of C++ was to make this code more
accessible to existing JS people who might also want to pitch in. I think this
is really key because a lot of people contribute to Firebug because its in a
language they already know and are familiar with. JavaScript code should not
immediately be assumed to be a "trivial" portion of a program.

All in all, I think boucher's reasoning behind this seemingly crucial title
was to get people excited about the "enhanced" WebKit profiler, not to somehow
imply the WebKit team has never done any work on this problem before or
something. I'm not sure that many people would have cared that much if he'd
written "minor/some bug fixes to safari profiler", especially if they had
already encountered some of these bugs in the past and had been turned off by
them initially, not to mention that the changes were indeed pretty
significant.

Trust us, we know the frustration. We love WebKit at 280 North and are
constantly saddened to hear that a lot of people don't even know about any of
WebKit's truly great debugging facilities.

~~~
bdash
Your post itself was entirely fair, and the improvements to the profiler were
great. It is only the title of this posting that I take issue with. If the
title had been "280 North makes WebKit's JavaScript Profiler Useful!" I don't
think it would be any less dramatic and would have been a lot less
contentious. It can be a little irksome knowing that someone put a huge amount
of work into the profiling infrastructure in JavaScriptCore and the UI in the
web inspector while the title, and the dozens of tweets it spawned, imply that
is all 280 North's doing.

We're all better off if we focus on doing great things and set the
sensationalism aside. Thanks again for the contributions to WebKit, and I hope
there are more going forwards!

------
benreesman
I think it's high time for Apple to break out the giant checkbook in the sky
and make these guys millionaires. These guys are literally inventing the
future of Apple's platform. The 280 guys look unstoppable to me.

~~~
falsestprophet
These guys are hackers of the old school. Every time I see something new from
those folks it puts me to shame.

All in all, I am terribly jealous.

~~~
benreesman
I feel the same way, I feel even more that way about the AppJet guys. I try to
use my envy of their obvious ability to motivate myself to work harder. It
seems to work. ;)

