Hacker News new | past | comments | ask | show | jobs | submit login

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!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact