On 05/10/2011 08:33 PM, Aryeh Gregor wrote:
On Tue, May 10, 2011 at 7:49 AM, Olli Pettay<olli.pet...@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?
Sure. If there are no listeners for spellcheck event, browser could
optimize it out.
But if there is the listener, event needs to be fired.
And note, the test where there was a listener is trivial
(just doing ++foo; ), so in real world web apps the
listener would take more time.
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.
That is tricky. What is being "visible"? The whole page might be
painted in Panorama-like thingie for example.
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?
Something like that might be better. Do you have the exact API in mind?
-Olli
