

A Hidden Cost of Javascript [updated] - aristus
http://carlos.bueno.org/2010/02/measuring-javascript-parse-and-load.html?v=2

======
gleb
JS loading is slow in FF, but the real killer is anything DOM related. On
large pages this is measured in seconds not milliseconds. The worst part is
that it scales non-linearly with # of DOM nodes on the page, # of DOM nodes
loaded in other tabs in FF, how long it's been running and who knows what
else.

The longer FF works on improvements on benchmarks on which it is already fast,
the more market share Chrome will take by making fast things that actually
matter.

~~~
gruseom
I agree 100% and have been complaining about exactly this for a long time
(e.g. <http://news.ycombinator.com/item?id=325742>). The fact that IE is the
whipping-boy of the web community has caused Firefox to get more of a free
ride than it deserves. That will eventually change.

------
docgnome
Sorta looks to me to confirm something we already knew, V8 blows everything
else away.

------
aristus
The exact versions of the browsers are available when you mouse over the
column headers.

------
pietro
Chrome is exceptionally fast, apparently.

~~~
aristus
It does appear fast, but I'm withholding judgement. I'm not certain if it's
doing caching tricks or whether their parser really is 10x faster. It
certainly is CPU-bound, which is as good as it gets, and it's more stable in
terms of memory use.

See this graph: <http://carlos.bueno.org/images/chrome-cliff.png>

------
gridspy
Some really nice timing graphs at the end there.

------
ShabbyDoo
It's notable how little FF improved between 3.5 and 3.6.

~~~
sp332
The big improvements in JS performance in 3.6 were in regex, GC, and tracing.

Edit: details at [http://hacks.mozilla.org/2010/01/javascript-speedups-in-
fire...](http://hacks.mozilla.org/2010/01/javascript-speedups-in-firefox-3-6/)

