Javascript Delegation performance considerations

Question

I looked for threads on performance increase using delegation mechanism. I am talking about simple javascript, without jQuery or other tools/libraries.

Every element spawns events in the DOM tree, and they travel throughout it with bubbling mechanism.

Delegation works avoiding to create an event handler for each element, but catching more events in a single handler. Also, stopping bubbling, the handler can avoid the event to further propagate, if already correctly handled. Thus it would reduce resource consumption by the page.

But, if bubbling is not stopped, events spawn and propagate through all the DOM tree, so there is the same resource consumption in the page using delegation or not. And, if the delegated handler has to perform check on the source of the event, it would be also more consuming...

So, where is the performance gain in using delegation, beyond programming being more easy, simple, clean?

There is a way to avoid certain events to generate at all, or certain elements to spawn certain events at all, thus saving really much in resource use? For example, a simple text, on mouse over, generates many useless messages in a normal page; if that message is not to be handled, can it be prevented to be generated at source?

Mortenson

Performance is so rarely an actual issue in JavaScript. Browsers spend most of their time idling while the user reads. Time between most input is measured in 10s or 100s of milliseconds (for typing, at best) that minor differences in performance (which would amount to 2-3ms) are not very noticeable. – Geyserite

Answer 1

But, if bubbling is not stopped, events spawn and propagate through all the DOM tree, so there is the same resource consumption in the page using delegation or not. And, if the delegated handler has to perform check on the source of the event, it would be also more consuming...

Events propagating through the DOM tree without any event listener associated, do not necessarily request browser memory usage. What does not request an action, may be not monitored at all. Modern browsers are highly optimized for better UI performance, and this type of memory waste would be the first issue to avoid in any elementary client.

The problem is not the high number of events generated from a UI which propagate through the DOM tree, but all the event listeners that the browser must save in memory for each element which has an event handler associated.

Imagine a web based file browser, which DOM tree contains elements representing files: even if loaded asynchronously, when the user expands lots of nodes it could finally show hundreds of elements at the same time.

Each element would surely have more event listeners, for example one to expand/collapse, one to intercept the right click to show a context menu, one for the left click to enable a drag and drop, one for the double click to perform some action and so on...
With 5 event listeners per element, in a simple file tree of 100 files you would incur into 500 event listeners to be managed by the browser, that's where a huge memory usage takes place.

So, where is the performance gain in using delegation, beyond programming being more easy, simple, clean?

In the example above, when you capture 5 events on a parent element (e.g. the tree container) instead than 500, you are requesting 99% actions less, so less memory allocation in the browser.
Then, each time one of the event monitored is fired, the selective activation of the proper action related to the right target means just running a function to find and apply the right handler.

In the web you can find other explanations regarding the low level memory management of browsers and the gain event delegation brings, but if you think not to rely on these sources, the best way is to make a test yourself, for example on a demanding widget which listens many events and uses animations, replicating it many times in the DOM and looking at the dynamic behaviour of the UI.

Cyclone