Re: Mutation events - slowness examples

Another couple of event timing test pages - hopefully the last.

test6.html is a 2000 row table.
The test sorts the table twice (and the table data is arranged so that 
each sort just reverses the row order).
The first sort has DOMNodeInserted and DOMNodeRemoved listeners. The 
second sort doesn't.
Results approx (without -> with listeners)
Firefox: 900ms -> 1100ms
Opera: 950ms -> 1150ms
Safari: 300ms -> 310ms


I guess you could argue that 900ms -> 1100ms is detrimental to UX.
I don't think 300ms -> 310ms is.


Of course, there is no guarantee of accuracy for timing of DOM Mutations 
when it is measured with Javascript.
Because the timing script cannot know when the browser has started to 
reflow / repaint it cannot account for it.
Some of the things that confirm this uncertainty:
- variable timings
- pages being repainted after the timing data is alerted
- pages not being repainted for intermediate stages of a test

Anyway, the best I can think of to avoid reflow uncertainty is to use 
simulated events.
Hence test7.html which dispatches 50000 DOMAttrModified events and 
reports Event Timings for:
1. dispatch (no handler attached)
2. create and dispatch (no handler attached)
3. create, init and dispatch (no handler attached)
4. create, init, dispatch and handler

Note that this is all done in Javascript, so I would expect that the 
internal timings are somewhat faster.
Results for 50000 events (all in ms):

Firefox - 1: 1380, 2: 2073, 3: 2815, 4: 3508

Opera - 1: 622, 2: 1304, 3: 1675, 4: 2721

Safari - 1: 121, 2: 192, 3: 318, 4: 379


I won't extrapolate this data or draw any conclusions, but at least it 
demonstrates that an event rate of over 100 per millisecond is achievable.

Sean

PS All testing done on a MacBook 2.0GHz Core 2 Duo, 2GB RAM, OS-X 10.4.11
Firefox 3.5rc3
Opera 9.60
Safari = Webkit nightlies