Live data from Hacker News

Mozilla's JM crosses Apple's Nitro threshold

arewefastyet.com

31–37 of 37 posts

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

#31
post #30
post #22

Earlier quoted context omitted.

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.

As I understand it, arewefastyet.com was created as more of an internal/community dashboard specifically for the JIT team at Mozilla rather than to reflect on the browser as a whole to the userbase.

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

#32
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…

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!)

Have you had problems where Firefox 4 just fails miserably to render a page, but if you refresh it renders fine?

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

#33
post #10

Earlier quoted context omitted.

And yet that's what people seem to like using it for. I still don't see why machine translated scheme is a good benchmark for fine tuning code. Javascript is a fine language to work in - especially if you are wanting to use it for things other than a browser (then you must really like it!).

I haven't seen the code but based on the description it's a benchmark that was originally in scheme and ported to javascript.. sounds fine to me. And "kernel simulation benchmark" may have a usecase too, just because you can't think of it, doesn't mean it isn't there ;) I can think of tests for scheduling, threading, asynchronous code, I/O when i think of "kernel simulation". Again, people like to use V8benchmarks, w…

If you create a benchmark that measures X, it will be used to measure Y. It's the rule of benchmarks.

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

#34
post #13

I bet slow JM has cost FireFox a pretty significant number of users over the last couple of years. Even the much smaller gap between nitro & v8 is noticeable at times.

You have no idea what you're talking about. If you recognize it as speculation, please don't do it when actual verification is such a simple process.

Pre-emptive note to readers: Sure "You have no idea what you're talking about" sounds harsh, but is it wrong? Please consider that before acting upon any knee-jerk reactions to my comment.

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

#35
I am always puzzled by the attention paid to JavaScript execution speed. Obviously, it's important (and should be) to the people who are intimately involved with the maintenance and development of the JavaScript engines, but apart from that, why do so many people in the web business care about it so much?

What sites and/or web apps are so JavaScript-heavy that they are bottlenecked by slow JavaScript execution?

In most cases, aren't the speed of a user's network connection and the responsiveness of the web server itself far more important to the user experience of a web app than the browser's JavaScript speed? Is GMail on Chrome really a radically different experience from GMail on IE8?

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

#36
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…

According to my friends that work at Mozilla, this site is purely for javascript speed and is what Mozilla uses as an internal motivator to motivate employees. Its a line everyone works to hit.

Its not really a "benchmark" to show the world that they're doing better. It's a public site because everything that happens in mozilla is open, but it's not really for us to see and judge. Its for the guys on the inside to see and cheer or see, then haul ass to catch up.

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

#37

I am always puzzled by the attention paid to JavaScript execution speed. Obviously, it's important (and should be) to the people who are intimately involved with the maintenance and development of the JavaScript engines, but apart from that, why do so many people in the web business care about it so much? What sites and/or web apps are so JavaScript-heavy that they are bottlenecked by slow JavaScript execution? In mo…

People are looking ahead to html 5, when real apps can be implemented entirely in a browser.
Post reply on HN