WebKit gets a new JavaScript profiler courtesy of 280 North (YC W08)

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.