
Extreme JavaScript Performance - sant0sk1
http://arstechnica.com/journals/linux.ars/2008/10/07/extreme-javascript-performance
======
gruseom
_The majority of most processing time in the most common of web pages is
consumed by issues unrelated (but not disconnected) to JavaScript
performance._

This is my bête noire. The app I work on, though very js-intensive, is
nevertheless performance-bound by these other constraints and has actually
gotten _slower_ under some recent browser releases (Firefox 3). Not just a
little slower, either: slower enough to become borderline-unusable. That's
ironic when everybody is slapping each other on the back about their enormous
performance advancements. "Of course it's faster. Look at these benchmarks!"
It reminds me of my old professor's anecdote. She was visiting her sister and
said "Oh, I'm cold." The sister went to look at the thermostat and said, "No
you're not, it's 20˚ in here!" (70˚F)

That being said, WebKit kicks Gecko's ass right now (at least for this
particular app). It renders and scrolls many times faster and in fact is just
shockingly good in Safari 3 (not quite as great in Chrome).

Edit: This comment sounds a bit grumpier than I intended. The main thing is
that browser innovation is back with a vengeance. Competition should sort all
this out in the long run.

~~~
tlrobinson
Indeed, DOM performance is often the real bottleneck.

In Cappuccino we go to great lengths to avoid touching the DOM wherever
possible. Views (which wrap DOM elements) keep track of their position and
size, so we never have to ask the DOM. We defer DOM manipulations to the end
of each "run loop" where we coalesce them, removing redundant operations.

The overhead of this bookkeeping (which is reduced by increase JS engine
performance) is less than the overhead of extra DOM operations, so it's worth
it.

We're already seeing other frameworks adopt some of these practices.

~~~
gruseom
_We defer DOM manipulations to the end of each "run loop" where we coalesce
them, removing redundant operations_

That's very interesting. Can you give examples of redundant operations that
you coalesce?

I'm wondering if this approach might help in my case. I'm frequently
repositioning/resizing thousands of little divs. Any suggestions?

~~~
tlrobinson
I'm not the expert on this among us, but from what I understand there are
situations where changing one thing causes something else to change and so
forth. The specific operations we coalesce are appending nodes, removing
nodes, setting the position and setting the size.

Are you changing the position of the divs multiple times per "event" (i.e.
mouse/keyboard event, etc) or just very frequently on separate events?

No idea how well this would work, but maybe you could have a timeout fire N
times per second (5, 10, 15, 30?) and update the DOM positions then? Though
with thousands of divs I don't know if that will help.

What are all these divs? Are they simple enough they could be drawn with
Canvas?

~~~
gruseom
_Are you changing the position of the divs multiple times per "event" (i.e.
mouse/keyboard event, etc) or just very frequently on separate events?_

Very frequently on separate events.

 _What are all these divs?_

The cells of a spreadsheet. (The pos/size resets happen as the user scrolls or
does something resizey. Oh, and the content of the divs changes under these
conditions too.)

 _Are they simple enough they could be drawn with Canvas?_

They're about as simple as you could get (at least before you add in
formatting and all that). I never considered Canvas as an option - do you
recommend trying it?

We might not need to do anything, since the deterioration in FF3 is already
getting better with the next release of FF (Shiretoko), though not as good as
FF2. On the other hand, performance of this particular UI is critical to its
user-acceptance, and if there's something we can do to get significant
improvement I'd probably go for it.

------
sadiq
Anyone know what the respective graphs look like for IE7 and the IE8 betas?

The sad thing is that no matter how fast Gecko, Webkit and Chrome's JS engines
are, you're probably going to have to design applications to cater for the
lowest common denominator, which will probably be IE (atleast from the IE7
benchmarks I can see).

~~~
gruseom
In the short term, sure. But if there are web apps people really like, and
they discover how much faster they run in a different browser, things will
change.

~~~
khafra
I'd also contend that, with the same frequency that it's good to create
something really good for a niche instead of ok for the majority, it's good to
create a fantastically capable ajax app that's only usable with tracemonkey,
v8, or squirrelfish. The other great part is that the niche you're writing for
is expanding geometrically.

