I wrote a post before the weekend about some performance issues with MooTools, DHTML and AJAX, but having found the solution to a related problem this morning, I wanted to post a followup.
I’ve been working with a large, dynamically generated and AJAX populated table that features sorting, filtering and row highlighting, and was finding that my table took a long time to render, and was also very slow to close - that is, when I tried to close the window or refresh the page, there would be a delay when the browser would first hang for a few seconds. IE often (but not always) popped up the error/prompt Stop this script running?, and Firefox less often threw it’s Unresponsive Script warning.
I’d heard of MooTools’ garbage collection functions that reduced memory leakage, and figured that these were probably responsible. I then found Kevin Smith’s write up of his similar experience, and came to understand the problem. MooTools’ garbage collection takes time to clean up any element that has been extended. My table was executing the following code, effectively extending every table row in the table, resulting in some 500+ extended elements.
// MooTools Code
Element.extend({
…
getChildren: function(){
return $$(this.childNodes);
},
…
});
…
// My Code
this.tablerows = this.body.getChildren();
When it came to cleanup, this javascript processing took longer than IE’s configured script timeout, and thus prompted the warning.
To avoid this cleanup overhead, you’ll have to avoid extending the elements with MooTools’ extensive set of functions and instead extend the specific elements in question with the specific functions required.
I first delved into javascript frameworks with Prototype, but I quickly realised that the Prototype+Script.aculo.us combination, even in Protocoluous or Protopackt form, was never going to work - it was just too slow.
I moved to MooTools, and for a while was pretty happy - load times were quicker, effects smoother.
But having recently tried to build sorting and filtering functionality into an HTML table of 200+ rows, I’ve been forced to take a closer look at how different browsers execute javascript, and at where the bottlenecks are. Here I’m going to promote a few best practices, largely via Julien LeComte at Yahoo.
Inserting new Elements
Working with the DOM in MooTools is a breeze - code like the following is a pleasure to write and to read:
var div = new Element(’div’, {id:’example’}).addClass(’example’).setHTML(’Example Content’).injectAfer(’previousElementID’);
However it’s worth noting that the Element class uses ‘document.createElement’, which is much more expensive than the alternative, albeit less readible innerHTML. Further, inject() and adopt() functions use appendChild() and are also thus very expensive. An it certainly feels like this effect is magnified when working with tables.
Changing Existing Elements
Working with with DOM can cause performance issues, but if the DOM element in question is not visible (display:none), or if the DOM element is ‘off-DOM’, you’ll acheive a performance gain.
Retrieving Values from the DOM
Retreiving values from the DOM is much more expensive than referencing a local variable:
// bad code
children.each(function(child) {
if (child.getText() == otherElement.getText()) alert(’slow’);
});
// good code
var text = otherElement.getText();
children.each(function(child) {
if (child.getText() == text) alert(’fast’);
});
Attaching Event Handlers
Attaching events is also very slow. To tackle this, instead of looping through multiple elements attaching events, attach the event handler to the parent, and within the handler detect which element has been clicked:
// bad code
children.each(function(child) {
child.addEvent(’mousedown’, function () {
alert(child.getText());
}
});
// good code
parent.addEvent(’mousedown’, function (e) {
var child = new Event(e).target;
alert(child.getText());
}
By applying these ideas, I was able to cut the processing time of loading a table by more than 70%, and hopefully you can benefit too.
