Hacker News Reader

Comment by robin_reala | Hacker News Reader

I’m not denying your results, but Webkit has nothing to do with the JS execution speed: Chrome and Safari use completely different JS engines and it doesn’t make sense to talk about ‘Webkit’ in this context.

View on HN

Good point. I'll clarify: Safari, WebKit nightlies, and Chrome perform very similarly in many cases, and tend to be faster than anyone else.

He meant that, as far as the tests in the main article, Webkit has nothing to do with the results. Chrome uses the V8 javascript engine, Safari uses the Nitro javascript engine, while the webkit project are building their own javascript engine - Squirellfish.

Nitro is what Squirrelfish was renamed in Apple's marketing materials after they shipped it in Safari.

I know. And they all perform very similarly under most conditions (now. Not in the past.). And they're all near the top of all the charts all the time.

For what it's worth, this test has little to do with JS execution speed. See https://bugzilla.mozilla.org/show_bug.cgi?id=622358#c3 for an analysis of a profile of the test in Firefox. In brief, 80% is canvas operations due to the emulator making 1024 putImageData calls for every single frame. The time spent actually running JS is about 10% of the total time.

I updated the page with a graph from FF4.0b9 which is a bit improved over b8. The Javascript is now respectively similar.

You're right about the 80/10 split. FF4's rendering speed is an outlier compared to Safari/Chrome/Opera on the same hardware. To better compare the faster browsers I'd need to run multiple emulators per page.

EDIT: b9 improved over 8, not itself.

Reply on news.ycombinator.com