-2

I'm trying to speed up the javascript execution in our app.

It looks like I've 900+ event listeners bound -

var listenerCount = 0;    
var ael = Node.prototype.addEventListener;
Node.prototype.addEventListener = function() {
     listenerCount++;
     ael.apply(this, arguments);
}

And I understand that this will be effecting performance. Is it possible to speed things up by adjusting the way I register listeners? For example if I try and register on events on the same element (with different selectors), will that be more efficient.

Eg changing

$('#sidebar').find('select').on('click', 'option', handler1);
$('#sidebar').find('.className').on('click', 'a', handler2);

for

$('#sidebar').on('click', 'select option', handler1);
$('#sidebar').on('click', '.className a', handler2);

Generally speaking I'm interested in the time it takes to register everything rather than the time it to actually run the handler (and I'm aware that different selectors perform differently). I'd probably swap an extra 10-50ms when the event is actually fired for 1-5ms reduction in registering the event - I want the app to load fast!

I was thinking of writing something that will do the selector matching so as to reduce the number of events actually registered, but I can't find anyone else doing anything similar (which makes me think it's probably dumb) -

var sideBarDomEvents = (function(){
    var clickEvents = [],
    my = {
      init: function() {
        $sidebar = $('#sidebar');
        $sidebar.on('click', function(e){
          for (var i=0; i < clickEvents.length; i++) {
            if (clickEvents[i]['target'] == $(e.target) {
              clickEvents[i]['handler'](e);
            }
          }
        });
      },
      registerClickEvent: function($target, handler){
        // This only works if the target is the inner most element - bubbling isn't supported!
        clickEvents.push({'target':$target, 'handler': handler});
      }
    }
    return my;
})();

I'm really not sure which way to go here - I don't even know where to measure this stuff (I certainly haven't noticed anything in Chrome's profile or timeline that relates). Any explanation of the performance effects of jquery events would be great.

Aidan Ewen
  • 13,049
  • 8
  • 63
  • 88
  • 2
    event delegation is not about **speed**. your question is too long and too vague. speed only perceived if you have a "poorly" written selector running over a lotttt of elements. that is slow, but not something humans will see probably. slow for computer. – vsync Dec 08 '14 at 17:46
  • 1
    you aren't going to be able to do anything better w/ jquery other than increasing the complexity of your code. – Daniel A. White Dec 08 '14 at 17:46
  • 1
    @vsync the question isn't vague or long. In fact the question is only one sentence long (and identified with a question mark) - "is it possible to speed things up by adjusting the way I register event listeners?". The rest is background info. – Aidan Ewen Dec 08 '14 at 18:59
  • @AidanEwen - How have you come to the conclusion things are "slow", and you want to speed them up? what is slow for you? too many events consume more memory, but 900 is not a high number in term of memory consumption, yet, event delegation should be done in a sensible way. – vsync Dec 09 '14 at 08:35
  • 1
    @vsync I came to the conclusion that things are slow by measuring the time it takes them to occur. I want to speed them up because that will improve user experience, and ultimately profitability. Our javascript application is slow. – Aidan Ewen Dec 11 '14 at 12:34

1 Answers1

0

Attaching the listeners to the same object makes actually attaching the listeners take less time, but the process of catching and handling the events will be slower.

Attaching the listeners closer to the target takes more time, but handlers will fire quicker when the event occurs.

Thanks to this question for the answer - Should all jquery events be bound to $(document)??

Community
  • 1
  • 1
Aidan Ewen
  • 13,049
  • 8
  • 63
  • 88
  • obviously not! why would you bind all events to the `document`? it's absurd. Apps and webpages have different components in them, so event delegation should be done on the component's top-most element in the DOM tree which wraps all component DOM. of course you could use the `document` but then you'll have to use very strict event namespacing to distinguish events and prevent event-collusion. – vsync Dec 09 '14 at 08:42
  • @vsync I would attach all my events to the document if it meant my page loaded 200ms faster (even if I incurred a 50ms lag when the events actually fire). – Aidan Ewen Dec 11 '14 at 12:35
  • events don't slow down you app for sure. please provide a link so I could examine the case. but it's not events which slow things down for sure, unless written in a complete mature way, like have an "endless" amount of DOM elements and attach thousands of events to them. which of course no sane person would do. – vsync Dec 11 '14 at 12:40