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.
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-.... 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.
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.
In some cases, this might fail to infer a name,
in which case, the function is listed with
the special name “[Anonymous]”.
IE suffers from the same problem the other profilers do. They may "try" to be smart, but there's no substitute for actually letting framework authors provide the most accurate information they can.
It looks like the IE version is a bit more clever, since it seems to grab the name of the function at the point it's first bound to a variable. Huge benefit being you don't have to go back an instrument your code with .displayName's everywhere.
Both Safari and Firebug employ similar "tricks" to try to infer the name. The point is that none of them is fool proof (especially in cases of generated functions), and its nice to have something to fall back on when you run into this problem.
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.
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.
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.
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.
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!
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.
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. ;)
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.