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