Javascript Performance Thread

[phuzi0n]

They just passed the 400ms mark for SS on the main page even though the regress page has worse numbers for the same revision. They've now met the original 400ms / 2300ms goals!

http://arewefastyet.com/

[bogas04]

WebKit ALMOST pwned

[patrickjdempsey]

That's pretty impressive stuff.

[WonderCsabo]

WebKit ALMOST pwned

Not yet. Really the purple line counts (JM+TM)

Anyone know what's the current goal?

[schapel]

The next goal is to be 15% faster than the Oct. 1 builds by the end of 2010 on SunSpider and V8. It looks like they're a third of the way there in just one week. When they reach the goal, Firefox should be about as fast as Chrome on SunSpider, but still about 40% slower than Chrome on v8. That's plenty fast enough for Firefox 4.0

[WonderCsabo]

Agreed!

The Oct 1 speed = AWFY oct 1 speed?

[phuzi0n]

Anyone know what's the current goal?

"15% improved over the October 1st numbers." to paraphrase the wiki which is linked a few pages back. It's worded in a way open to interpretation. It could either be [Oct 1st]/1.15 (15% faster) or [Oct 1st]*0.85 (15% less execution time). AWFY reports the latter. It works out to something around ~350ms SS and ~1900ms V8 but varies a little depending on the exact math.

[phuzi0n]

Agreed!

The Oct 1 speed = AWFY oct 1 speed?

Yes. You can just look at the Sept. 29th speed because nothing major changed between then and Oct. 1.

[WonderCsabo]

Yeah, i meant that, thanks for the aswers guys!

So the goals are:

350 ms on SS
2040 ms on V8

Am i correct?

[Terepin]

The improvements are great and all, but until they fix UI freezing during rendering, they'll be useless.

[WonderCsabo]

The improvements are great and all, but until they fix UI freezing during rendering, they'll be useless.

What do yo point at exactly? This? https://bugzilla.mozilla.org/show_bug.cgi?id=593614

[Terepin]

In general to this: https://bugzilla.mozilla.org/show_bug.cgi?id=599546

[phuzi0n]

The improvements are great and all, but until they fix UI freezing during rendering, they'll be useless.

What do yo point at exactly? This? https://bugzilla.mozilla.org/show_bug.cgi?id=593614

Try interacting with the GUI while the V8 benchmark is running and you'll understand. FF still has the GUI running in the same process as content so the GUI lags/freezes if content is hammering the CPU. All those bugs linked to the meta bug have nothing to do with the real problem. Until the GUI is separated into its own process all sorts of content will cause the GUI to lag/freeze.

[WonderCsabo]

I see.

There will be no separated thing in Fx4.0. Maybe this would help, but nobody working on it: https://bugzilla.mozilla.org/show_bug.cgi?id=598873

[Ver Greeneyes]

You don't need a separate process to allow things to run in parallel, just use a separate thread. They might not currently be able to, I dunno (the advantages to running things in a different process are 1) if one process crashes it doesn't take the whole browser down 2) you can theoretically use 32-bit and 64-bit code side by side - but even the OOPP stuff doesn't do this yet, if it ever will).