bdash

I think this is because an A record query for www.kodefund.com returns multiple CNAME records, which is not compliant with the DNS specification:

    mrowe@vega:~$ dig A www.kodefund.com @a.dns.gandi.net
    
    ; <<>> DiG 9.8.1-P1 <<>> A www.kodefund.com @a.dns.gandi.net
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53562
    ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
    ;; WARNING: recursion requested but not available
    
    ;; QUESTION SECTION:
    ;www.kodefund.com.		IN	A
    
    ;; ANSWER SECTION:
    www.kodefund.com.	10800	IN	CNAME	intense-ocean-3642.herokuapp.com.
    www.kodefund.com.	10800	IN	CNAME	mie-9107.herokussl.com.
    
    ;; Query time: 125 msec
    ;; SERVER: 173.246.97.2#53(173.246.97.2)
    ;; WHEN: Sun Jul 29 16:47:59 2012
    ;; MSG SIZE  rcvd: 110
    

If I perform the same query via my system resolver rather than directly against the gandi.net DNS servers then I simply receive no result:

    mrowe@vega:~$ dig A www.kodefund.com
    
    ; <<>> DiG 9.8.1-P1 <<>> A www.kodefund.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36608
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
    
    ;; QUESTION SECTION:
    ;www.kodefund.com.		IN	A
    
    ;; Query time: 1306 msec
    ;; SERVER: 192.168.1.254#53(192.168.1.254)
    ;; WHEN: Sun Jul 29 16:48:58 2012
    ;; MSG SIZE  rcvd: 34
    

This is presumably because one of the intermediate resolver is being strict about the presence of multiple CNAMEs in the result.

Hmm… it looks like I misspoke. The "sparse mode" check that Array.prototype.sort performs in JavaScriptCore appears to be different than the its concept of sparse array storage, which is used under the conditions I described. The "sparse mode" check in the sorting code appears to be related to whether the array instance has getters/setters or properties defined via Object.defineProperty. The performance difference my code demonstrates is due to the extra overhead of iterating the sparse array storage compared to a vector, and not due to the different sorting algorithms that are employed.

Apple engineers contributed "Nitro" to the WebKit SVN repository before it even gained that name.

The version of JavaScriptCore (and the rest of WebKit) available from svn.webkit.org is exactly what is shipped in Safari on OS X.

Can you point me at some code comparing the performance of your JavaScript quicksort implementation to the browser's native sort? I threw together a quick comparison myself and couldn't see any cases where the JavaScript implementation was significantly faster than JavaScriptCore's Array.prototype.sort, and there were a few cases where Array.prototype.sort was significantly faster than the JS implementation.

EDIT: One interesting case is that of sparse arrays (e.g., the arrays which trigger JavaScriptCore to fall down the slow path that prompted this discussion). It seems that your JavaScript quicksort implementation doesn't handle these correctly: it gives different results from Array.prototype.sort and is dramatically slower as well. I'm guessing the performance impact comes from the fact that from JavaScript's point of view the holes in the array are identical undefined values. I'm not sure why correctness would be affected though.

This is also fast in Safari because the array isn't sparse enough for JavaScriptCore to send it down the fallback path.

EDIT: In order to go down the fallback path the array needs to be both sufficiently large and sufficiently sparse (< 12.5% occupied). You can see the difference in algorithms by modifying your test case like so:

Dense, fast path:

    var a = [];
    for (var i = 1; i < 4e6; i++)
      a[i * 5] = i.toString();
    a.sort();

Sparse, fallback path:

    var a = [];
    for (var i = 1; i < 4e6; i++)
      a[i * 10] = i.toString();
    a.sort();

The AVL tree is used for sorting when there is a custom comparison function because we cannot guarantee that the user-provided comparison function conforms to the requirements of the underlying standard library sort functions. Websites have a habit of providing nonsense comparison functions (e.g., using function() { return 0.5 - Math.random(); } to "shuffle" via sorting) and we need to ensure that these sorts will give terminate.

EDIT: Sparse mode is when JSC::JSArray switches from storing the array data as a vector to storing it in a map. You can see from the code at http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/r... that a vector will be used for sufficiently small arrays (< 10,000 elements) and for larger arrays that are at least 12.5% full.

> A well-designed OS shouldn't require you to keep multiple versions installed on a machine like that.

A well-designed OS should require you to install a separate version of Python if the version it provides does not suit your needs. Replacing the system version of Python means that any system components that use Python are now running in an untested configuration and may break in mysterious ways. Installing your new version elsewhere removes that concern.

> prepackaged versions of Python won't always install properly if you already have a Python on your system.

If a prepackaged version of Python for Mac OS X won't install if you already have Python on your system, then it's broken. It's that simple. Mac OS X has shipped with Python installed for years, so such a package would not install on any modern Mac OS X installation.

> I mean take a look at the installation instructions for Matplotlib.

I don't know that using Matplotlib as an example really supports your argument.

The installation notes about Mac OS X are a mess, but from my reading of that page it says as much about Matplotlib as it does about the state of Python on Mac OS X. On that page they recommend a third-party distribution of Python named EPD, but then go on to talk about how EPD has issues building Matplotlib on some versions of Mac OS X. Why would they recommend a version of Python that can't build their software? The page also spends a bunch of time talking about older versions of Matplotlib, and about packaging mechanisms that they no longer use. Neither of those things are relevant to the average person that is getting up and running with Matplotlib on Mac OS X.

As far as I can see Matplotlib only distributes binaries for Mac OS X that require the Python.org version of Python to be installed. With such a version of Python installed, the process for installing Matplotlib appears to be as simple as: 1) Install NumPy from http://sourceforge.net/projects/numpy/files/NumPy/1.6.1/ 2) Install Matplotlib from http://sourceforge.net/projects/matplotlib/files/matplotlib/....

As far as I can tell, this is exactly the same process as for Matplotlib on Windows. Right down to installing a version of Python from python.org. I'm not even sure that's strictly necessary. The hand-wavy mention of problems with the system version of Python on the installation page are so void of context and detail that they're impossible to evaluate.

Upgrading the system Python on Mac OS X isn't easy because it's not something you should do. See http://stackoverflow.com/a/1541850 for something of an explanation about this.

Amusingly enough, Mail’s compose window uses WebKit for the content area. According to http://webkit.org/b/73888 the issue is specific to the WebKit2 layer that is currently used only by Safari.

Try the YouTube5 extension for a happy medium between ClickToFlash and Flash.

Yup. It’s really unfortunate.

I prefer to opt out of YouTube’s HTML5 mode and use the YouTube5 extension to achieve a similar effect. It also has the added benefit of avoiding the Flash player on videos where YouTube chooses not to use the HTML5 player.

Do you have Perian installed? Does http://www.youtube.com/html5 report that Safari supports WebM? If so, then what you’re seeing is YouTube preferring WebM over h.264, even though h.264 decoding is hardware accelerated rather than the software decoding that Perian’s WebM support provides. You can try temporarily disabling Perian, relaunching Safari, and then watching a video again to see whether the performance is more in line with your expectations.

That sandbox violation is not coming from your application. WebProcess is the process used for rendering web content in Safari only.

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!

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.

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.

Except for the fact that the real definition is actually more like:

    #ifdef __cplusplus
    #define __DARWIN_NULL __null
    #else /* ! __cplusplus */
    #define __DARWIN_NULL ((void *)0)
    #endif /* __cplusplus */

So the code you mentioned works just fine in C++.