- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Tue, 10 May 2011 13:33:42 -0400
- To: Olli@pettay.fi
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
On Tue, May 10, 2011 at 7:49 AM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote: > Just a quick test on Nokia N900 (which is already a bit old mobile > phone) using a recent browser: > dispatching 10000 events to a deep (depth 100) DOM (without > listeners for the event - for testing purposes) takes about 3 seconds. How did you test this? Specifically, couldn't a real-world browser optimize by not dispatching the events at all unless there's a listener? > If there is a listener, the test takes 4-5s per 10000 events. > > If the DOM is shallow, the test without listeners takes about 1s, > and with a listener about 2-3s. > > This is just one browser engine, but based on my testing on desktop, the > differences between browser engines aren't in order of > magnitude in this case. > On a fast desktop those tests take 50-200ms. > > So, tens of thousands events doesn't sounds like a fast enough > solution for mobile devices, but would be ok for desktop, I think. For a worst case this might be okay, if everyone agrees with me that an event-based API would be vastly better for authors. Particularly if browsers only dispatch the event when the words are visible. Alternatively, the API could be changed so that the browser is allowed to dispatch one spellcheck event for as many words as it likes, and the event object would just have arrays where I had scalar values: it would pass in an array of words, and expect an array of arrays of suggestions in return. How does that sound?
Received on Tuesday, 10 May 2011 17:57:12 UTC