Safari WebKit beta closing the gap against Chrome 4, Opera a very close second

In the latest check of progress in the development of the major Web browsers for Windows, the brand that helped Betanews launch its regular browser performance tests appears to be making a comeback effort: With each new daily build, the WebKit browser engine -- running in Apple's Safari 4.0.5 chassis -- gains computational speed that it was sorely lacking.

Safari already leads Google Chrome in the rendering department, and posts scalability scores comparable to Opera 10.51, in Betanews' Windows 7 Relative Performance Index suite. In this morning's round of tests using WebKit daily build 56417 on Windows 7, Safari scored a very respectable 20.27, coming up just behind the latest stable Chrome 4.1 at 21.22.

To compete effectively against Chrome and Opera, Safari/WebKit has needed to post better SunSpider computational test scores. There's definite improvement in that department, though Safari still has a ways to go: Today's 55.74 relative score (almost 56 times better than Microsoft Internet Explorer 7's score on Windows Vista SP2) reflects apparent improvement in the test browser's date handling and string manipulation functions; in all other SunSpider categories, the test browser ties or just barely exceeds the stable Safari 4 scores. Safari 4 scores 48.87 overall on the SunSpider, while Chrome 4.1 scores 59.31. The latest dev build of Chrome 5 is the SunSpider leader with 75.82, followed by the stable Opera 10.51 with 70.70.

In the SlickSpeed CSS selectors battery, the daily Safari/WebKit is now running away with the lead with a 13.87 score over Opera 10.51 at 12.19, and the Chrome 5 dev build at 12.83. That shows how adept the new WebKit code is at manipulating CSS components in memory; anyone wanting to be "the HTML 5 browser" will need to master this department. But in the old school of layout -- the HTML 1 <TABLE> element -- Safari/WebKit also shows poise with an 8.26 score. Only Chrome 4.1 is ahead in that department with an impressive 9.49.

It's with the new DFScale suite that I've intended to learn more of the whys-and-wherefores of browsers' performance. Overall, Safari/WebKit's speed score is in the middle of the field (37.12 versus Chrome 5's 53.90), but its scalability scores are quite respectable (9.40 versus 10.93, respectively). What that means is, WebKit is very adept at finding new efficiencies when working with heavier workloads -- a process I call "finding another gear."

You can see this process at work in the numbers for the Merge Sort test: The stable Safari 4 took 8 ms (.008 seconds) to sort a 500-unit array, and 20.1 seconds to sort a 25,000 unit array. If the Merge Sort problem scaled linearly (it doesn't), it would have taken Safari 4 0.4 seconds to sort the larger array. With the daily WebKit doing the JavaScript and rendering instead, the browser sorts the same 25,000 unit array in 9.8 seconds.

This same phenomenon would probably make Safari/WebKit the leader in the Heap Sort test as well, if it were capable of running the 10 million iteration test along with Chrome. For the Heap Sort grid numbers it can run (up to 1 million), it scales very impressively, starting out just about even with the latest Opera 10.52 snapshot (released yesterday), but then beating it at 1 million iterations at 3.1 versus 4.1 seconds. Safari/WebKit has a better time with scaling exponential problems higher than with linear problems like Euler's Problem #14.

Long-time readers will recall there used to be a browser called Firefox that figured prominently in tests like ours. Well, the news hasn't been good for Firefox in recent days, especially with scores from the daily builds of version 3.7 alpha dipping a few tenths (even after a scoring adjustment, see below), from 10.76 last week to 10.23 today.

One of the most stark differences in the way browsers work is revealed in the results of the Problem #14 test, between Firefox and Safari. Our "How it works and why" report goes into detail about the two phases of this test, called "naïve" and "optimized." In assembling successive chains of numbers that follow two math rules, eventually one chain will run into a value that appears at the head of another chain. At that point, the "optimized" version of the test appends that other chain onto the end of the current one, while the "naïve" version blindly moves forward through to the end of the chain.

The Safari/WebKit daily build executes the "naïve" 1 million iteration Problem #14 test in about 7.9 seconds; and it shaves over three seconds off that mark in the "optimized" version, for a 4.7 seconds total. By comparison, the latest daily build of Firefox 3.7 Alpha 4 takes 94 seconds to run the "naïve" test. But optimization scales that number down to 6.8 seconds, which actually beats the stable Safari 4's 6.9 seconds. The suggestion here is that Firefox tends...to...slow...way...do...wn as a chain gets longer and longer, whereas Safari only slows down very slightly. Again, this gets to the whole issue of scalability: the ability to find the extra gear as the workload increases.

Now, a slight scoring methodology change to note since our report last week: In the new DFScale suite, I noticed that variations in the time values for the lower grid numbers made for less-than-desirable oscillations in the averages. For example, in a few cases, a test where a browser would perform in 3 ms half the time and 2 ms the other half (when the real value is probably more like 2.5), would jostle the averages wildly. So for the time being, I'm not counting the time values in the lowest one or two grid numbers as among the time averages, although they still count as points toward scalability. The adjustment did affect the score for the IE9 Platform Preview...on the positive side. We're now scoring it at 13.38 overall, a few ticks above last week.