Live data from Hacker News

Mozilla's JM crosses Apple's Nitro threshold

arewefastyet.com

21–30 of 37 posts

Re: Mozilla's JM crosses Apple's Nitro threshold

#21
post #19

I have heard from the V8 developers that Mozilla do some optimizations just to score better on benchmarks - i.e. they score really good on things that are specifically benchmarked. I have not verified their claim, but generally for me as an user Chrome and Safari feel a lot faster than Firefox.

Two quick points (I work at Mozilla, but not on the browser - I'm also the creator of the Dromaeo performance benchmark): All browsers implement things to get faster at these benchmarks. They implement caching in bizarre places just to make an, otherwise, useless loop faster. They optimize methods that are rarely used in modern JavaScript applications. This frustrates me immensely. Most modern browser performance benchmarks focus exclusively on JavaScript and completely ignore the DOM, rendering, painting, or any of the other operations that are critical to the performance of a web site.

As to the faster claim - I've been using Firefox 3.6, Chrome, Safari 5, and Firefox 4 interchangeably and I've noticed a dramatic improvement in quality from Firefox 3.6 to Firefox 4 - they've really done a great job with the upcoming release.

Re: Mozilla's JM crosses Apple's Nitro threshold

#22
post #20

A good browser benchmark would also measure: 1. Browser boot time. 2. Browser shutdown time (on clicking Close). 3. Tab boot time. 4. Tab shutdown time. 5. LocalStorage boot time (on first call to LocalStorage API, some browsers load LocalStorage into memory at this point, blocking the UI). 6. IO performance of LocalStorage, WebSQLDatabase, IndexedDB for massive get/set operations (bandwidth) and many get/set operati…

Agreed that most of these would be good components of an overall browser benchmark, but the linked benchmarks are JavaScript benchmarks only, so things like browser start-up time and chrome dimensions wouldn't apply.

Re: Mozilla's JM crosses Apple's Nitro threshold

#23
post #21
post #19

I have heard from the V8 developers that Mozilla do some optimizations just to score better on benchmarks - i.e. they score really good on things that are specifically benchmarked. I have not verified their claim, but generally for me as an user Chrome and Safari feel a lot faster than Firefox.

Two quick points (I work at Mozilla, but not on the browser - I'm also the creator of the Dromaeo performance benchmark): All browsers implement things to get faster at these benchmarks. They implement caching in bizarre places just to make an, otherwise, useless loop faster. They optimize methods that are rarely used in modern JavaScript applications. This frustrates me immensely. Most modern browser performance ben…

Especially Sunspider, which has the doubly whammy of developer and to a certain extent power-user mindshare, but yet doesn’t test normal site behaviour.

Re: Mozilla's JM crosses Apple's Nitro threshold

#24
post #21
post #19

I have heard from the V8 developers that Mozilla do some optimizations just to score better on benchmarks - i.e. they score really good on things that are specifically benchmarked. I have not verified their claim, but generally for me as an user Chrome and Safari feel a lot faster than Firefox.

Two quick points (I work at Mozilla, but not on the browser - I'm also the creator of the Dromaeo performance benchmark): All browsers implement things to get faster at these benchmarks. They implement caching in bizarre places just to make an, otherwise, useless loop faster. They optimize methods that are rarely used in modern JavaScript applications. This frustrates me immensely. Most modern browser performance ben…

Agreed. I'm just using development builds (and lately the official beta), but Firefox 4 is leaps and bounds better than Firefox 3.6 (which was already pretty good!)

Re: Mozilla's JM crosses Apple's Nitro threshold

#25
post #15

Earlier quoted context omitted.

That's true, but machine-generated code can be pretty nutty, depending on what exactly the Scheme2JS compiler does. It's legitimate JS code, but it might not be representative of what JS-written-in-JS looks like.

True, but i see that this is a valid testcase. For example GWT generates JS out of Java, so it might be useful to also benchmark machinegenerated JS.

I think it'd be useful to benchmark GWT-generated JS (and also Objective-J), but not Scheme2Js, which is rarely if ever used in practice. Compilers for different languages will emit code with completely different performance characteristics and feature usage patterns. (For instance, Objective-J particularly stresses the call site caching mechanisms in modern JavaScript engines with its "objc_msgSend" equivalent, since the indirect call in that function branches to so many different call sites.)

Re: Mozilla's JM crosses Apple's Nitro threshold

#26
post #20

A good browser benchmark would also measure: 1. Browser boot time. 2. Browser shutdown time (on clicking Close). 3. Tab boot time. 4. Tab shutdown time. 5. LocalStorage boot time (on first call to LocalStorage API, some browsers load LocalStorage into memory at this point, blocking the UI). 6. IO performance of LocalStorage, WebSQLDatabase, IndexedDB for massive get/set operations (bandwidth) and many get/set operati…

I think 1 - 4 were what really kickstarted Chrome. Everyone else was focused on how many milliseconds difference between their rendering and js vs. the next guys, when Google shaved whole seconds off something that really matters.

Re: Mozilla's JM crosses Apple's Nitro threshold

#27
post #21

Earlier quoted context omitted.

Two quick points (I work at Mozilla, but not on the browser - I'm also the creator of the Dromaeo performance benchmark): All browsers implement things to get faster at these benchmarks. They implement caching in bizarre places just to make an, otherwise, useless loop faster. They optimize methods that are rarely used in modern JavaScript applications. This frustrates me immensely. Most modern browser performance ben…

Especially Sunspider, which has the doubly whammy of developer and to a certain extent power-user mindshare, but yet doesn’t test normal site behaviour.

Sunspider is a particularly bad benchmark: Virtually all of the components are heavily weighted by string concatenation.

http://www.yafla.com/dforbes/String_Concatenation_and_Immuta...

Re: Mozilla's JM crosses Apple's Nitro threshold

#28
post #18

This appears to be what got them there: http://andreasgal.wordpress.com/2010/10/13/compartments/ Also worth noting, there is no longer a gigantic "NO" down at the bottom of the page. :)

I miss that "NO". I expected to see "YES!", or maybe "MAYBE" in its place, but there's nothing there.

Yeah I was hoping for MAYBE, and then if it ever gets quicker than chrome a YES!

Re: Mozilla's JM crosses Apple's Nitro threshold

#29
post #20

A good browser benchmark would also measure: 1. Browser boot time. 2. Browser shutdown time (on clicking Close). 3. Tab boot time. 4. Tab shutdown time. 5. LocalStorage boot time (on first call to LocalStorage API, some browsers load LocalStorage into memory at this point, blocking the UI). 6. IO performance of LocalStorage, WebSQLDatabase, IndexedDB for massive get/set operations (bandwidth) and many get/set operati…

Mozilla measures many of these at http://graphs.mozilla.org/. "Ts" is startup time; "Tshutdown" is shutdown time; "GFX" includes 8 I believe.

Re: Mozilla's JM crosses Apple's Nitro threshold

#30
post #22
post #20

A good browser benchmark would also measure: 1. Browser boot time. 2. Browser shutdown time (on clicking Close). 3. Tab boot time. 4. Tab shutdown time. 5. LocalStorage boot time (on first call to LocalStorage API, some browsers load LocalStorage into memory at this point, blocking the UI). 6. IO performance of LocalStorage, WebSQLDatabase, IndexedDB for massive get/set operations (bandwidth) and many get/set operati…

Agreed that most of these would be good components of an overall browser benchmark, but the linked benchmarks are JavaScript benchmarks only, so things like browser start-up time and chrome dimensions wouldn't apply.

When users think "fast", they think "fast" as in "fast", not "JM fast" or "TM fast". It would be better for "arewefastyet.com" to address "fast" from the point of view of the user rather than from the point of view of the Javascript engine developer.
Post reply on HN