views:

208

answers:

7

I'm using jQuery. I have website feature that does an ajax search and returns a JSON result. The ajax callback then populates the rows of a table with the results. Generally, there are 100 rows per search that get inserted. Each row has a fair amount of data.

The code looks something like this (very much abbreviated):

function search() {

  $.post("/search.php", { params: search_params }, searchDone, "json");

}

function searchDone(json) {

    var $table = $("#result_table");
    var html = "";
    for(i=0; i < json.results.length; i++) {

       html += rowHtml(results[i]);

    }

    $table.append(html);

}

function rowHtml(result) { /* much simplified version */

  var html = "<tr><td>";
  html += result.field1;
  html += "</td><td>";
  html += result.field2;
  html += "</td></tr>";
  return html;

}

The performance is slow. The browser tends to lock up when the html is appended to the table.

Any advice on how to optimize this? Would it be better for me to create the dom nodes rather than try to get jQuery to render the HTML?

+4  A: 

You can try to push to an array and then append using array.join.

Are you always appending to the table? If not you should wrap all the rows in a tbody and then replace the existing tbody node. This is faster as it is really only one append rather than x.

UPDATE

Perf tests here by Mr Padolsey

redsquare
I do actually append to the table more than once, but I may be able to modify the behavior slightly if I can improve the performance.
jonstjohn
Double buffering FTW (yet again).
seth
sorry seth, don't think I get the reference
jonstjohn
nor me !
redsquare
A: 

There might be some pointers here:

http://stackoverflow.com/questions/589120/jquery-and-appending-large-amounts-of-html

Overall it seems that using Array.join vs string concatenation for a speed boost is a myth that has been dispelled - or I should say that in earlier versions of browsers, yes, Array.join was faster. But recent versions of browsers have greatly optimized String concatenation.

Cody Caughlan
A: 

You can use setTimeout instead of a for loop. It will not lock up the browser when it is building the long HTML string. You also might want to try append it as a entire tbody instead of just rows.

epascarello
+1  A: 

Set all the html at once instead of relying on DOM insertion.

function searchDone(json) {
    var $table = $("#result_table");
    var html = $table.html();
    for(i=0; i < json.results.length; i++) {
       html += rowHtml(results[i]);
    }
    $table.html($table.html() + html);
}
Duncan Beevers
This will yield no better performance than what the asker has already. Plus, `append` is not a global function.
Crescent Fresh
A: 

You should also use faster version of 'for' loop like: var $table = $("#result_table"); var html = "";

for(var i=0, var len= json.results.length; i < ; i++) {

  // etc...

}
Plugawy
+1  A: 

jQuery takes all those <tr>'s in your html string and creates them as DOM nodes (fast), appending them one by one (slow).

Try using a single <tbody> to hold your rows, then jQuery only has to append 1 element to the table:

var html = ["<tbody>"];
for(i=0, len=json.results.length; i < len; i++) {

   html.push(rowHtml(json.results[i]));

}
html.push("</tbody>");
$table.append(html.join(''));

As you can see I also did a couple of other micro-optimizations: cache the .length property in the loop, and use an array as a string buffer. They don't gain you much but are worth knowing.

Crescent Fresh
This is promising. I'm going to try it out first thing tomorrow. I suspected that the row insertions were causing the bottleneck, since the performance is directly tied to the number of rows.
jonstjohn
A: 

A little off-topic, but I use and recommend Javascript Rocks. This books contains a TON of awesome JS optimisation advice by the creator of Scriptaculous. Also comes with a tool called DOM Monster which helps track down performance bottlenecks - it's an awesome compliment to Firebug as it actually tracks through the DOM looking for inefficiencies based on heuristics and DOM complexity.

Toby Hede