I need tips on optimizing a large DOM insert to lessen the "freeze" on
the browser.
Scenario:
I receive a large amount of JSON 'data' through AJAX from a database
(sorted the way I want viewed), and loop through them to add to a JS
string, and insert that chunk of string into a tbody of a table. Then,
I run a plug-in that formats the table (with pagination, etc.).
Simplified sample code:
var html = '';
$.each(data, function(i, row) {
html += '<tr><td>data from json</td></tr>';
formatTable() requires that the table has to be "completed" before it
can be executed.
Is there any way I can optimize this better? I think I've read
somewhere that making a string too long is not good, but I've also
read that updating the DOM on each iteration is even worst.
> Concatenating into a string is already much faster than appending in
> each loop, there is not much room for improvement left. What you can
> do improve user experience though is split that into a recursive
> function over a setTimeout, so that the browser doesn't freeze and you
> can display a nice loading animation.
> James wrote:
> > I need tips on optimizing a large DOM insert to lessen the "freeze" on
> > the browser.
> > Scenario:
> > I receive a large amount of JSON 'data' through AJAX from a database
> > (sorted the way I want viewed), and loop through them to add to a JS
> > string, and insert that chunk of string into a tbody of a table. Then,
> > I run a plug-in that formats the table (with pagination, etc.).
> > Simplified sample code:
> > var html = '';
> > $.each(data, function(i, row) {
> > html += '<tr><td>data from json</td></tr>';
> > });
> > $("tbody").append(html);
> > $("table").formatTable();
> > formatTable() requires that the table has to be "completed" before it
> > can be executed.
> > Is there any way I can optimize this better? I think I've read
> > somewhere that making a string too long is not good, but I've also
> > read that updating the DOM on each iteration is even worst.
function loadTable( rows ) { var out = [], o = -1; out[++o] = '<table><tbody>'; for( var row, iRow = -1; row = rows[++iRow]; ) { out[++o] = '<tr><td>'; out[++o] = row.whatever; out[++o] = '</td></tr>'; } out[++o] = '</tbody></table>'; $('#container').html( out.join('') ); }
This is faster for several reasons:
* Explicit for loop (and the fastest kind of for loop) - no function callback for each row.
* Builds an array of string fragments and then joins it, instead of string concatenation.
* Buils the array with "out[++o] = ..." instead of the more obvious "out.push(...)" (faster in IE).
* Instead of inserting a large number of sibling DOM elements (the TRs) together, inserts only a single DOM element (the TABLE).
Note that the for loop will fail if the array may have null/false/zero/empty string elements. This is usually a safe assumption if each 'row' in the JSON data is actually an object, e.g.
> I need tips on optimizing a large DOM insert to lessen the > "freeze" on the browser.
> Scenario: > I receive a large amount of JSON 'data' through AJAX from a > database (sorted the way I want viewed), and loop through > them to add to a JS string, and insert that chunk of string > into a tbody of a table. Then, I run a plug-in that formats > the table (with pagination, etc.). > Simplified sample code:
> var html = ''; > $.each(data, function(i, row) { > html += '<tr><td>data from json</td></tr>'; }); > $("tbody").append(html); $("table").formatTable();
> formatTable() requires that the table has to be "completed" > before it can be executed. > Is there any way I can optimize this better? I think I've > read somewhere that making a string too long is not good, but > I've also read that updating the DOM on each iteration is even worst.
> I see. Thanks for the tip. I'll try to work on that!
> On Feb 5, 10:38 am, Ricardo Tomasi <ricardob...@gmail.com> wrote:
> > Concatenating into a string is already much faster than appending in
> > each loop, there is not much room for improvement left. What you can
> > do improve user experience though is split that into a recursive
> > function over a setTimeout, so that the browser doesn't freeze and you
> > can display a nice loading animation.
> > James wrote:
> > > I need tips on optimizing a large DOM insert to lessen the "freeze" on
> > > the browser.
> > > Scenario:
> > > I receive a large amount of JSON 'data' through AJAX from a database
> > > (sorted the way I want viewed), and loop through them to add to a JS
> > > string, and insert that chunk of string into a tbody of a table. Then,
> > > I run a plug-in that formats the table (with pagination, etc.).
> > > Simplified sample code:
> > > var html = '';
> > > $.each(data, function(i, row) {
> > > html += '<tr><td>data from json</td></tr>';
> > > });
> > > $("tbody").append(html);
> > > $("table").formatTable();
> > > formatTable() requires that the table has to be "completed" before it
> > > can be executed.
> > > Is there any way I can optimize this better? I think I've read
> > > somewhere that making a string too long is not good, but I've also
> > > read that updating the DOM on each iteration is even worst.
> > > Any advice would be appreciated!- Hide quoted text -
> I see. Thanks for the tip. I'll try to work on that!
> On Feb 5, 10:38 am, Ricardo Tomasi <ricardob...@gmail.com> wrote:
> > Concatenating into a string is already much faster than appending in
> > each loop, there is not much room for improvement left. What you can
> > do improve user experience though is split that into a recursive
> > function over a setTimeout, so that the browser doesn't freeze and you
> > can display a nice loading animation.
> > James wrote:
> > > I need tips on optimizing a large DOM insert to lessen the "freeze" on
> > > the browser.
> > > Scenario:
> > > I receive a large amount of JSON 'data' through AJAX from a database
> > > (sorted the way I want viewed), and loop through them to add to a JS
> > > string, and insert that chunk of string into a tbody of a table. Then,
> > > I run a plug-in that formats the table (with pagination, etc.).
> > > Simplified sample code:
> > > var html = '';
> > > $.each(data, function(i, row) {
> > > html += '<tr><td>data from json</td></tr>';
> > > });
> > > $("tbody").append(html);
> > > $("table").formatTable();
> > > formatTable() requires that the table has to be "completed" before it
> > > can be executed.
> > > Is there any way I can optimize this better? I think I've read
> > > somewhere that making a string too long is not good, but I've also
> > > read that updating the DOM on each iteration is even worst.
> > > Any advice would be appreciated!- Hide quoted text -
> Concatenating into a string is already much faster than > appending in each loop, there is not much room for > improvement left. What you can do improve user experience > though is split that into a recursive function over a > setTimeout, so that the browser doesn't freeze and you can > display a nice loading animation.
> On Feb 5, 5:03 pm, James <james.gp....@gmail.com> wrote: > > I need tips on optimizing a large DOM insert to lessen the > "freeze" on > > the browser.
> > Scenario: > > I receive a large amount of JSON 'data' through AJAX from a > database > > (sorted the way I want viewed), and loop through them to > add to a JS > > string, and insert that chunk of string into a tbody of a > table. Then, > > I run a plug-in that formats the table (with pagination, etc.). > > Simplified sample code:
> > var html = ''; > > $.each(data, function(i, row) { > > html += '<tr><td>data from json</td></tr>';});
> > formatTable() requires that the table has to be "completed" > before it > > can be executed. > > Is there any way I can optimize this better? I think I've read > > somewhere that making a string too long is not good, but I've also > > read that updating the DOM on each iteration is even worst.
> Try them in IE, where the performance is the worst and matters the most.
> On my test machine, the first one runs about 6.3 seconds and the second one > about 0.13 seconds.
> -Mike
>> From: Ricardo Tomasi
>> Concatenating into a string is already much faster than >> appending in each loop, there is not much room for >> improvement left. What you can do improve user experience >> though is split that into a recursive function over a >> setTimeout, so that the browser doesn't freeze and you can >> display a nice loading animation.
>> On Feb 5, 5:03 pm, James <james.gp....@gmail.com> wrote: >> > I need tips on optimizing a large DOM insert to lessen the >> "freeze" on >> > the browser.
>> > Scenario: >> > I receive a large amount of JSON 'data' through AJAX from a >> database >> > (sorted the way I want viewed), and loop through them to >> add to a JS >> > string, and insert that chunk of string into a tbody of a >> table. Then, >> > I run a plug-in that formats the table (with pagination, etc.). >> > Simplified sample code:
>> > var html = ''; >> > $.each(data, function(i, row) { >> > html += '<tr><td>data from json</td></tr>';});
>> > formatTable() requires that the table has to be "completed" >> before it >> > can be executed. >> > Is there any way I can optimize this better? I think I've read >> > somewhere that making a string too long is not good, but I've also >> > read that updating the DOM on each iteration is even worst.
One question, is there a difference between a loop with a running variable (e.g. for (i=0; i<rows.length; i++) ) and a for-in loop (e.g. for (var i in rows) )?
I've done some tests and couldn't find any performance difference beside the normal variation between two different measurements. Which variant should be preferred?
>> Try them in IE, where the performance is the worst and matters the most.
>> On my test machine, the first one runs about 6.3 seconds and the second one >> about 0.13 seconds.
>> -Mike
>>> From: Ricardo Tomasi
>>> Concatenating into a string is already much faster than >>> appending in each loop, there is not much room for >>> improvement left. What you can do improve user experience >>> though is split that into a recursive function over a >>> setTimeout, so that the browser doesn't freeze and you can >>> display a nice loading animation.
>>> On Feb 5, 5:03 pm, James <james.gp....@gmail.com> wrote: >>> > I need tips on optimizing a large DOM insert to lessen the >>> "freeze" on >>> > the browser.
>>> > Scenario: >>> > I receive a large amount of JSON 'data' through AJAX from a >>> database >>> > (sorted the way I want viewed), and loop through them to >>> add to a JS >>> > string, and insert that chunk of string into a tbody of a >>> table. Then, >>> > I run a plug-in that formats the table (with pagination, etc.). >>> > Simplified sample code:
>>> > var html = ''; >>> > $.each(data, function(i, row) { >>> > html += '<tr><td>data from json</td></tr>';});
>>> > formatTable() requires that the table has to be "completed" >>> before it >>> > can be executed. >>> > Is there any way I can optimize this better? I think I've read >>> > somewhere that making a string too long is not good, but I've also >>> > read that updating the DOM on each iteration is even worst.
.each isn't the best choice in this case, a good old-fashioned for
loop will be significantly faster.
Also, use an array of strings instead of a single one and string
concatenation. Using array.push () is faster than using the +=
operator on a string. Once the loop finishes use join () to get the
array's contents as a single string.
var myArray = [];
for (var i=0; i < data.length; i++)
{
myArray.push ('<tr><td>data from json</td></tr>');
}
$('tbody').append (myArray.join (''));
On Feb 5, 7:03 pm, James <james.gp....@gmail.com> wrote:
> I need tips on optimizing a large DOM insert to lessen the "freeze" on
> the browser.
> Scenario:
> I receive a large amount of JSON 'data' through AJAX from a database
> (sorted the way I want viewed), and loop through them to add to a JS
> string, and insert that chunk of string into a tbody of a table. Then,
> I run a plug-in that formats the table (with pagination, etc.).
> Simplified sample code:
> var html = '';
> $.each(data, function(i, row) {
> html += '<tr><td>data from json</td></tr>';});
> formatTable() requires that the table has to be "completed" before it
> can be executed.
> Is there any way I can optimize this better? I think I've read
> somewhere that making a string too long is not good, but I've also
> read that updating the DOM on each iteration is even worst.
> .each isn't the best choice in this case, a good old-fashioned for > loop will be significantly faster.
> Also, use an array of strings instead of a single one and string > concatenation. Using array.push () is faster than using the += > operator on a string. Once the loop finishes use join () to get the > array's contents as a single string.
> var myArray = [];
> for (var i=0; i < data.length; i++) > { > myArray.push ('<tr><td>data from json</td></tr>'); > }
> $('tbody').append (myArray.join (''));
> On Feb 5, 7:03 pm, James <james.gp....@gmail.com> wrote: > > I need tips on optimizing a large DOM insert to lessen the "freeze" on > > the browser.
> > Scenario: > > I receive a large amount of JSON 'data' through AJAX from a database > > (sorted the way I want viewed), and loop through them to add to a JS > > string, and insert that chunk of string into a tbody of a table. Then, > > I run a plug-in that formats the table (with pagination, etc.). > > Simplified sample code:
> > var html = ''; > > $.each(data, function(i, row) { > > html += '<tr><td>data from json</td></tr>';});
> > formatTable() requires that the table has to be "completed" before it > > can be executed. > > Is there any way I can optimize this better? I think I've read > > somewhere that making a string too long is not good, but I've also > > read that updating the DOM on each iteration is even worst.
> -----Original Message----- > From: jquery-en@googlegroups.com [mailto:jquery-en@googlegroups.com] On Behalf Of Michael Geary > Sent: Thursday, February 05, 2009 10:26 PM > To: jquery-en@googlegroups.com > Subject: [jQuery] Re: Optimize large DOM inserts
> "...there is not much room for improvement left."
> You just know that when you say that, someone will come along with a 20x-40x > improvement. ;-)
Ouch. That's quite a difference. I thought about the join vs
concatenate performance difference in IE, but didn't remember it could
be that large. I take that one, I was being displiscent.
cheers,
- ricardo
On Feb 6, 1:25 am, "Michael Geary" <m...@mg.to> wrote:
> Try them in IE, where the performance is the worst and matters the most.
> On my test machine, the first one runs about 6.3 seconds and the second one
> about 0.13 seconds.
> -Mike
> > From: Ricardo Tomasi
> > Concatenating into a string is already much faster than
> > appending in each loop, there is not much room for
> > improvement left. What you can do improve user experience
> > though is split that into a recursive function over a
> > setTimeout, so that the browser doesn't freeze and you can
> > display a nice loading animation.
> > On Feb 5, 5:03 pm, James <james.gp....@gmail.com> wrote:
> > > I need tips on optimizing a large DOM insert to lessen the
> > "freeze" on
> > > the browser.
> > > Scenario:
> > > I receive a large amount of JSON 'data' through AJAX from a
> > database
> > > (sorted the way I want viewed), and loop through them to
> > add to a JS
> > > string, and insert that chunk of string into a tbody of a
> > table. Then,
> > > I run a plug-in that formats the table (with pagination, etc.).
> > > Simplified sample code:
> > > var html = '';
> > > $.each(data, function(i, row) {
> > > html += '<tr><td>data from json</td></tr>';});
> > > formatTable() requires that the table has to be "completed"
> > before it
> > > can be executed.
> > > Is there any way I can optimize this better? I think I've read
> > > somewhere that making a string too long is not good, but I've also
> > > read that updating the DOM on each iteration is even worst.
Big thanks for the optimization!
It certainly did optimize the loop processing by several folds!
However, for my case, I found that the ultimate bottleneck was the
plug-in function that I was using that froze the browser the longest.
The actual insert to the DOM took a bit of time also and did freeze
the browser, but wasn't too bad even in IE6.
By the way, do you have any tips on emptying a large amount of content
in the DOM?
Such as emptying that whole chunk of HTML that was inserted. That also
freezes the browser also.
I'm currently using $(el).empty(); and not sure if there's a more
optimal solution.
Thanks!
On Feb 5, 5:25 pm, "Michael Geary" <m...@mg.to> wrote:
> Try them in IE, where the performance is the worst and matters the most.
> On my test machine, the first one runs about 6.3 seconds and the second one
> about 0.13 seconds.
> -Mike
> > From: Ricardo Tomasi
> > Concatenating into a string is already much faster than
> > appending in each loop, there is not much room for
> > improvement left. What you can do improve user experience
> > though is split that into a recursive function over a
> > setTimeout, so that the browser doesn't freeze and you can
> > display a nice loading animation.
> > On Feb 5, 5:03 pm, James <james.gp....@gmail.com> wrote:
> > > I need tips on optimizing a large DOM insert to lessen the
> > "freeze" on
> > > the browser.
> > > Scenario:
> > > I receive a large amount of JSON 'data' through AJAX from a
> > database
> > > (sorted the way I want viewed), and loop through them to
> > add to a JS
> > > string, and insert that chunk of string into a tbody of a
> > table. Then,
> > > I run a plug-in that formats the table (with pagination, etc.).
> > > Simplified sample code:
> > > var html = '';
> > > $.each(data, function(i, row) {
> > > html += '<tr><td>data from json</td></tr>';});
> > > formatTable() requires that the table has to be "completed"
> > before it
> > > can be executed.
> > > Is there any way I can optimize this better? I think I've read
> > > somewhere that making a string too long is not good, but I've also
> > > read that updating the DOM on each iteration is even worst.
I remember this being discussed long ago on the 'replaceHTML' subject.
Apparently using .innerHTML on an element that is not in the DOM is
much faster (except for IE which is already fast). See here:
> Big thanks for the optimization!
> It certainly did optimize the loop processing by several folds!
> However, for my case, I found that the ultimate bottleneck was the
> plug-in function that I was using that froze the browser the longest.
> The actual insert to the DOM took a bit of time also and did freeze
> the browser, but wasn't too bad even in IE6.
> By the way, do you have any tips on emptying a large amount of content
> in the DOM?
> Such as emptying that whole chunk of HTML that was inserted. That also
> freezes the browser also.
> I'm currently using $(el).empty(); and not sure if there's a more
> optimal solution.
> Thanks!
> On Feb 5, 5:25 pm, "Michael Geary" <m...@mg.to> wrote:
> > "...there is not much room for improvement left."
> > You just know that when you say that, someone will come along with a 20x-40x
> > improvement. ;-)
> > Try them in IE, where the performance is the worst and matters the most.
> > On my test machine, the first one runs about 6.3 seconds and the second one
> > about 0.13 seconds.
> > -Mike
> > > From: Ricardo Tomasi
> > > Concatenating into a string is already much faster than
> > > appending in each loop, there is not much room for
> > > improvement left. What you can do improve user experience
> > > though is split that into a recursive function over a
> > > setTimeout, so that the browser doesn't freeze and you can
> > > display a nice loading animation.
> > > On Feb 5, 5:03 pm, James <james.gp....@gmail.com> wrote:
> > > > I need tips on optimizing a large DOM insert to lessen the
> > > "freeze" on
> > > > the browser.
> > > > Scenario:
> > > > I receive a large amount of JSON 'data' through AJAX from a
> > > database
> > > > (sorted the way I want viewed), and loop through them to
> > > add to a JS
> > > > string, and insert that chunk of string into a tbody of a
> > > table. Then,
> > > > I run a plug-in that formats the table (with pagination, etc.).
> > > > Simplified sample code:
> > > > var html = '';
> > > > $.each(data, function(i, row) {
> > > > html += '<tr><td>data from json</td></tr>';});
> > > > formatTable() requires that the table has to be "completed"
> > > before it
> > > > can be executed.
> > > > Is there any way I can optimize this better? I think I've read
> > > > somewhere that making a string too long is not good, but I've also
> > > > read that updating the DOM on each iteration is even worst.
Wow! Wow! Wow! Using that replaceHTML function to empty out the
element took practically no time at all!
Though I wasn't able to get it to work properly in IE (tried only IE6)
as oldEl.innerHTML = html; kept bombing on me with "unknown runtime
error". I've removed the IE-only part and let it run the rest. It's
still many times faster than using $(el).empty();
However, I wasn't able to get replaceHTML to work on inserting HTML
into the DOM though. Using the previous suggestions, it would become:
replaceHtml('myElementID', out.join(''));
but the inserted HTML in 'myElementID' had all of the HTML tags (<tr>,
<td>, etc.) stripped out for some reason.
On Feb 6, 11:48 am, Ricardo Tomasi <ricardob...@gmail.com> wrote:
> I remember this being discussed long ago on the 'replaceHTML' subject.
> Apparently using .innerHTML on an element that is not in the DOM is
> much faster (except for IE which is already fast). See here:
> On Feb 6, 6:28 pm, James <james.gp....@gmail.com> wrote:
> > Big thanks for the optimization!
> > It certainly did optimize the loop processing by several folds!
> > However, for my case, I found that the ultimate bottleneck was the
> > plug-in function that I was using that froze the browser the longest.
> > The actual insert to the DOM took a bit of time also and did freeze
> > the browser, but wasn't too bad even in IE6.
> > By the way, do you have any tips on emptying a large amount of content
> > in the DOM?
> > Such as emptying that whole chunk of HTML that was inserted. That also
> > freezes the browser also.
> > I'm currently using $(el).empty(); and not sure if there's a more
> > optimal solution.
> > Thanks!
> > On Feb 5, 5:25 pm, "Michael Geary" <m...@mg.to> wrote:
> > > "...there is not much room for improvement left."
> > > You just know that when you say that, someone will come along with a 20x-40x
> > > improvement. ;-)
> > > Try them in IE, where the performance is the worst and matters the most.
> > > On my test machine, the first one runs about 6.3 seconds and the second one
> > > about 0.13 seconds.
> > > -Mike
> > > > From: Ricardo Tomasi
> > > > Concatenating into a string is already much faster than
> > > > appending in each loop, there is not much room for
> > > > improvement left. What you can do improve user experience
> > > > though is split that into a recursive function over a
> > > > setTimeout, so that the browser doesn't freeze and you can
> > > > display a nice loading animation.
> > > > On Feb 5, 5:03 pm, James <james.gp....@gmail.com> wrote:
> > > > > I need tips on optimizing a large DOM insert to lessen the
> > > > "freeze" on
> > > > > the browser.
> > > > > Scenario:
> > > > > I receive a large amount of JSON 'data' through AJAX from a
> > > > database
> > > > > (sorted the way I want viewed), and loop through them to
> > > > add to a JS
> > > > > string, and insert that chunk of string into a tbody of a
> > > > table. Then,
> > > > > I run a plug-in that formats the table (with pagination, etc.).
> > > > > Simplified sample code:
> > > > > var html = '';
> > > > > $.each(data, function(i, row) {
> > > > > html += '<tr><td>data from json</td></tr>';});
> > > > > formatTable() requires that the table has to be "completed"
> > > > before it
> > > > > can be executed.
> > > > > Is there any way I can optimize this better? I think I've read
> > > > > somewhere that making a string too long is not good, but I've also
> > > > > read that updating the DOM on each iteration is even worst.
> Wow! Wow! Wow! Using that replaceHTML function to empty out the
> element took practically no time at all!
> Though I wasn't able to get it to work properly in IE (tried only IE6)
> as oldEl.innerHTML = html; kept bombing on me with "unknown runtime
> error". I've removed the IE-only part and let it run the rest. It's
> still many times faster than using $(el).empty();
> However, I wasn't able to get replaceHTML to work on inserting HTML
> into the DOM though. Using the previous suggestions, it would become:
> replaceHtml('myElementID', out.join(''));
> but the inserted HTML in 'myElementID' had all of the HTML tags (<tr>,
> <td>, etc.) stripped out for some reason.
> On Feb 6, 11:48 am, Ricardo Tomasi <ricardob...@gmail.com> wrote:
> > Now I might have something useful to say! :)
> > I remember this being discussed long ago on the 'replaceHTML' subject.
> > Apparently using .innerHTML on an element that is not in the DOM is
> > much faster (except for IE which is already fast). See here:
> > On Feb 6, 6:28 pm, James <james.gp....@gmail.com> wrote:
> > > Big thanks for the optimization!
> > > It certainly did optimize the loop processing by several folds!
> > > However, for my case, I found that the ultimate bottleneck was the
> > > plug-in function that I was using that froze the browser the longest.
> > > The actual insert to the DOM took a bit of time also and did freeze
> > > the browser, but wasn't too bad even in IE6.
> > > By the way, do you have any tips on emptying a large amount of content
> > > in the DOM?
> > > Such as emptying that whole chunk of HTML that was inserted. That also
> > > freezes the browser also.
> > > I'm currently using $(el).empty(); and not sure if there's a more
> > > optimal solution.
> > > Thanks!
> > > On Feb 5, 5:25 pm, "Michael Geary" <m...@mg.to> wrote:
> > > > "...there is not much room for improvement left."
> > > > You just know that when you say that, someone will come along with a 20x-40x
> > > > improvement. ;-)
> > > > Try them in IE, where the performance is the worst and matters the most.
> > > > On my test machine, the first one runs about 6.3 seconds and the second one
> > > > about 0.13 seconds.
> > > > -Mike
> > > > > From: Ricardo Tomasi
> > > > > Concatenating into a string is already much faster than
> > > > > appending in each loop, there is not much room for
> > > > > improvement left. What you can do improve user experience
> > > > > though is split that into a recursive function over a
> > > > > setTimeout, so that the browser doesn't freeze and you can
> > > > > display a nice loading animation.
> > > > > On Feb 5, 5:03 pm, James <james.gp....@gmail.com> wrote:
> > > > > > I need tips on optimizing a large DOM insert to lessen the
> > > > > "freeze" on
> > > > > > the browser.
> > > > > > Scenario:
> > > > > > I receive a large amount of JSON 'data' through AJAX from a
> > > > > database
> > > > > > (sorted the way I want viewed), and loop through them to
> > > > > add to a JS
> > > > > > string, and insert that chunk of string into a tbody of a
> > > > > table. Then,
> > > > > > I run a plug-in that formats the table (with pagination, etc.).
> > > > > > Simplified sample code:
> > > > > > var html = '';
> > > > > > $.each(data, function(i, row) {
> > > > > > html += '<tr><td>data from json</td></tr>';});
> > > > > > formatTable() requires that the table has to be "completed"
> > > > > before it
> > > > > > can be executed.
> > > > > > Is there any way I can optimize this better? I think I've read
> > > > > > somewhere that making a string too long is not good, but I've also
> > > > > > read that updating the DOM on each iteration is even worst.
I run into a similar problem. Replacing parts of tables does not work with IE. (see http://de.selfhtml.org/javascript/objekte/all.htm#inner_html, sorry available in German only) Now I simply replacing the whole table which is still much faster than my previous version.
> Wow! Wow! Wow! Using that replaceHTML function to empty out the > element took practically no time at all! > Though I wasn't able to get it to work properly in IE (tried only IE6) > as oldEl.innerHTML = html; kept bombing on me with "unknown runtime > error". I've removed the IE-only part and let it run the rest. It's > still many times faster than using $(el).empty();
> However, I wasn't able to get replaceHTML to work on inserting HTML > into the DOM though. Using the previous suggestions, it would become: > replaceHtml('myElementID', out.join(''));
> but the inserted HTML in 'myElementID' had all of the HTML tags (<tr>, > <td>, etc.) stripped out for some reason.
> On Feb 6, 11:48 am, Ricardo Tomasi <ricardob...@gmail.com> wrote: >> Now I might have something useful to say! :)
>> I remember this being discussed long ago on the 'replaceHTML' subject. >> Apparently using .innerHTML on an element that is not in the DOM is >> much faster (except for IE which is already fast). See here:
>> On Feb 6, 6:28 pm, James <james.gp....@gmail.com> wrote:
>> > Big thanks for the optimization! >> > It certainly did optimize the loop processing by several folds!
>> > However, for my case, I found that the ultimate bottleneck was the >> > plug-in function that I was using that froze the browser the longest. >> > The actual insert to the DOM took a bit of time also and did freeze >> > the browser, but wasn't too bad even in IE6.
>> > By the way, do you have any tips on emptying a large amount of content >> > in the DOM? >> > Such as emptying that whole chunk of HTML that was inserted. That also >> > freezes the browser also. >> > I'm currently using $(el).empty(); and not sure if there's a more >> > optimal solution. >> > Thanks!
>> > On Feb 5, 5:25 pm, "Michael Geary" <m...@mg.to> wrote:
>> > > "...there is not much room for improvement left."
>> > > You just know that when you say that, someone will come along with a 20x-40x >> > > improvement. ;-)
>> > > Try them in IE, where the performance is the worst and matters the most.
>> > > On my test machine, the first one runs about 6.3 seconds and the second one >> > > about 0.13 seconds.
>> > > -Mike
>> > > > From: Ricardo Tomasi
>> > > > Concatenating into a string is already much faster than >> > > > appending in each loop, there is not much room for >> > > > improvement left. What you can do improve user experience >> > > > though is split that into a recursive function over a >> > > > setTimeout, so that the browser doesn't freeze and you can >> > > > display a nice loading animation.
>> > > > On Feb 5, 5:03 pm, James <james.gp....@gmail.com> wrote: >> > > > > I need tips on optimizing a large DOM insert to lessen the >> > > > "freeze" on >> > > > > the browser.
>> > > > > Scenario: >> > > > > I receive a large amount of JSON 'data' through AJAX from a >> > > > database >> > > > > (sorted the way I want viewed), and loop through them to >> > > > add to a JS >> > > > > string, and insert that chunk of string into a tbody of a >> > > > table. Then, >> > > > > I run a plug-in that formats the table (with pagination, etc.). >> > > > > Simplified sample code:
>> > > > > var html = ''; >> > > > > $.each(data, function(i, row) { >> > > > > html += '<tr><td>data from json</td></tr>';});
>> > > > > formatTable() requires that the table has to be "completed" >> > > > before it >> > > > > can be executed. >> > > > > Is there any way I can optimize this better? I think I've read >> > > > > somewhere that making a string too long is not good, but I've also >> > > > > read that updating the DOM on each iteration is even worst.
There's no need to use that function to insert the HTML, as the
performance improvement comes mostly from emptying the element outside
the DOM.
To avoid the memory leak, you'd have to remove all the event listeners
before destroying it - that's exactly what empty() does (+ clearing
any data), and the source of most of it's overhead. You can probably
get around that by not attaching any events to the inner elements and
use event delegation on the <table> or live() instead.
You might get away with something like this, not sure if it will
perform any better:
var c = $('#container')[0],
parent = c.parentNode,
next = c.nextSibling,
old = parent.removeChild(c);
c = old.cloneNode(false).innerHTML = out.join('');
if (next)
next.insertBefore(c);
else
parent.appendChild(c);
setTimeout(function(){ $(old).remove(); }, 200); //give the browser
some breathing time then clean up events&data from the old element
The cleaning up part will be unnecessary if you use event delegation.
- ricardo
On Feb 6, 9:17 pm, James <james.gp....@gmail.com> wrote:
> I just noticed in IE6 that using the replaceHTML to clear the DOM with
> events attached definitely creates memory leak. FF seems to clean it
> up though.
> On Feb 6, 1:06 pm, James <james.gp....@gmail.com> wrote:
> > Wow! Wow! Wow! Using that replaceHTML function to empty out the
> > element took practically no time at all!
> > Though I wasn't able to get it to work properly in IE (tried only IE6)
> > as oldEl.innerHTML = html; kept bombing on me with "unknown runtime
> > error". I've removed the IE-only part and let it run the rest. It's
> > still many times faster than using $(el).empty();
> > However, I wasn't able to get replaceHTML to work on inserting HTML
> > into the DOM though. Using the previous suggestions, it would become:
> > replaceHtml('myElementID', out.join(''));
> > but the inserted HTML in 'myElementID' had all of the HTML tags (<tr>,
> > <td>, etc.) stripped out for some reason.
> > On Feb 6, 11:48 am, Ricardo Tomasi <ricardob...@gmail.com> wrote:
> > > Now I might have something useful to say! :)
> > > I remember this being discussed long ago on the 'replaceHTML' subject.
> > > Apparently using .innerHTML on an element that is not in the DOM is
> > > much faster (except for IE which is already fast). See here:
> > > On Feb 6, 6:28 pm, James <james.gp....@gmail.com> wrote:
> > > > Big thanks for the optimization!
> > > > It certainly did optimize the loop processing by several folds!
> > > > However, for my case, I found that the ultimate bottleneck was the
> > > > plug-in function that I was using that froze the browser the longest.
> > > > The actual insert to the DOM took a bit of time also and did freeze
> > > > the browser, but wasn't too bad even in IE6.
> > > > By the way, do you have any tips on emptying a large amount of content
> > > > in the DOM?
> > > > Such as emptying that whole chunk of HTML that was inserted. That also
> > > > freezes the browser also.
> > > > I'm currently using $(el).empty(); and not sure if there's a more
> > > > optimal solution.
> > > > Thanks!
> > > > On Feb 5, 5:25 pm, "Michael Geary" <m...@mg.to> wrote:
> > > > > "...there is not much room for improvement left."
> > > > > You just know that when you say that, someone will come along with a 20x-40x
> > > > > improvement. ;-)
> > > > > Try them in IE, where the performance is the worst and matters the most.
> > > > > On my test machine, the first one runs about 6.3 seconds and the second one
> > > > > about 0.13 seconds.
> > > > > -Mike
> > > > > > From: Ricardo Tomasi
> > > > > > Concatenating into a string is already much faster than
> > > > > > appending in each loop, there is not much room for
> > > > > > improvement left. What you can do improve user experience
> > > > > > though is split that into a recursive function over a
> > > > > > setTimeout, so that the browser doesn't freeze and you can
> > > > > > display a nice loading animation.
> > > > > > On Feb 5, 5:03 pm, James <james.gp....@gmail.com> wrote:
> > > > > > > I need tips on optimizing a large DOM insert to lessen the
> > > > > > "freeze" on
> > > > > > > the browser.
> > > > > > > Scenario:
> > > > > > > I receive a large amount of JSON 'data' through AJAX from a
> > > > > > database
> > > > > > > (sorted the way I want viewed), and loop through them to
> > > > > > add to a JS
> > > > > > > string, and insert that chunk of string into a tbody of a
> > > > > > table. Then,
> > > > > > > I run a plug-in that formats the table (with pagination, etc.).
> > > > > > > Simplified sample code:
> > > > > > > var html = '';
> > > > > > > $.each(data, function(i, row) {
> > > > > > > html += '<tr><td>data from json</td></tr>';});
> > > > > > > formatTable() requires that the table has to be "completed"
> > > > > > before it
> > > > > > > can be executed.
> > > > > > > Is there any way I can optimize this better? I think I've read
> > > > > > > somewhere that making a string too long is not good, but I've also
> > > > > > > read that updating the DOM on each iteration is even worst.
These test pages DO NOT accurately compare the speed of array.join("")
VS string+="...". The biggest speed difference between the two is
REALLY that one uses $("<table></table>") and one doesn't. If this is
removed from the 'slow' page, the load-speed goes from 8.7 sec to 1.5
sec. This is still 6-times longer than the fast version - but no
longer 30-times longer!
Conversely, I changed the 'fast' page to use the append syntax (after
removing <table> and <tbody> from the array):
This changed the 'fast' load from 0.24 sec to 7.3 sec! So even the
'fast loop' page performed 30-times slower when the element-append
method is used!
There was another code difference as well - the fast page uses $
('#container').html() and the slow-page $('#container').append().
However, since the container is empty, it does not cause any
significant speed difference.
So for a TRUE loop-speed comparison, the code for the 'slow version'
should be:
var html = '<table><tbody>';
$.each( rows, function( iRow, row ) {
html += '<tr><td>' + row.text + '</td></tr>';
});
html += '</tbody></table>';
$('#container').html( html );
This now uses the same html() syntax as the fast version, isolating
the difference between the pages to ONLY the 2 loops. Now there is
less than a 1.3 sec difference - instead of 8+ seconds.
Now it becomes clear that the biggest lesson here is that append
("<table<</table>") is a much bigger problem than the loop code. This
is important to know because it would apply even if there were NO loop
at all!
Thanks for bringing both these details to my attention. I do a lot of
dynamic HTML generation, so it's helpful to know what to watch out
for.
/Kevin
On Feb 5, 7:25 pm, "Michael Geary" <m...@mg.to> wrote:
> Try them in IE, where the performance is the worst and matters the most.
> On my test machine, the first one runs about 6.3 seconds and the second one
> about 0.13 seconds.
> -Mike
> > From: Ricardo Tomasi
> > Concatenating into a string is already much faster than
> > appending in each loop, there is not much room for
> > improvement left. What you can do improve user experience
> > though is split that into a recursive function over a
> > setTimeout, so that the browser doesn't freeze and you can
> > display a nice loading animation.
> > On Feb 5, 5:03 pm, James <james.gp....@gmail.com> wrote:
> > > I need tips on optimizing a large DOM insert to lessen the
> > "freeze" on
> > > the browser.
> > > Scenario:
> > > I receive a large amount of JSON 'data' through AJAX from a
> > database
> > > (sorted the way I want viewed), and loop through them to
> > add to a JS
> > > string, and insert that chunk of string into a tbody of a
> > table. Then,
> > > I run a plug-in that formats the table (with pagination, etc.).
> > > Simplified sample code:
> > > var html = '';
> > > $.each(data, function(i, row) {
> > > html += '<tr><td>data from json</td></tr>';});
> > > formatTable() requires that the table has to be "completed"
> > before it
> > > can be executed.
> > > Is there any way I can optimize this better? I think I've read
> > > somewhere that making a string too long is not good, but I've also
> > > read that updating the DOM on each iteration is even worst.
> > > Any advice would be appreciated!- Hide quoted text -
I never claimed that these pages reflect only the difference between the array join and string concatenation. On the contrary, in my other message in this thread I listed all of the factors that make the code faster:
* Explicit for loop (and the fastest kind of for loop) - no function callback for each row.
* Builds an array of string fragments and then joins it, instead of string concatenation.
* Builds the array with "out[++o] = ..." instead of the more obvious "out.push(...)" (faster in IE).
* Instead of inserting a large number of sibling DOM elements (the TRs) together, inserts only a single DOM element (the TABLE).
Now it is very useful to know how much of the performance improvement is due to each of these individual tricks, and thank you for doing that testing. My purpose in posting was to combine all of the optimizations to create the fastest possible code.
> These test pages DO NOT accurately compare the speed of > array.join("") VS string+="...". The biggest speed difference > between the two is REALLY that one uses $("<table></table>") > and one doesn't. If this is removed from the 'slow' page, the > load-speed goes from 8.7 sec to 1.5 sec. This is still > 6-times longer than the fast version - but no longer 30-times longer!
> Conversely, I changed the 'fast' page to use the append > syntax (after removing <table> and <tbody> from the array):
> This changed the 'fast' load from 0.24 sec to 7.3 sec! So > even the 'fast loop' page performed 30-times slower when the > element-append method is used!
> There was another code difference as well - the fast page uses $ > ('#container').html() and the slow-page $('#container').append(). > However, since the container is empty, it does not cause any > significant speed difference.
> So for a TRUE loop-speed comparison, the code for the 'slow version' > should be:
> var html = '<table><tbody>'; > $.each( rows, function( iRow, row ) { > html += '<tr><td>' + row.text + '</td></tr>'; }); html += > '</tbody></table>'; $('#container').html( html );
> This now uses the same html() syntax as the fast version, > isolating the difference between the pages to ONLY the 2 > loops. Now there is less than a 1.3 sec difference - instead > of 8+ seconds.
> Now it becomes clear that the biggest lesson here is that append > ("<table<</table>") is a much bigger problem than the loop > code. This is important to know because it would apply even > if there were NO loop at all!
> Thanks for bringing both these details to my attention. I do > a lot of dynamic HTML generation, so it's helpful to know > what to watch out for.
> /Kevin
> On Feb 5, 7:25 pm, "Michael Geary" <m...@mg.to> wrote: > > "...there is not much room for improvement left."
> > You just know that when you say that, someone will come > along with a > > 20x-40x improvement. ;-)
> > Try them in IE, where the performance is the worst and > matters the most.
> > On my test machine, the first one runs about 6.3 seconds and the > > second one about 0.13 seconds.
> > -Mike
> > > From: Ricardo Tomasi
> > > Concatenating into a string is already much faster than > appending in > > > each loop, there is not much room for improvement left. > What you can > > > do improve user experience though is split that into a recursive > > > function over a setTimeout, so that the browser doesn't > freeze and > > > you can display a nice loading animation.
> > > On Feb 5, 5:03 pm, James <james.gp....@gmail.com> wrote: > > > > I need tips on optimizing a large DOM insert to lessen the > > > "freeze" on > > > > the browser.
> > > > Scenario: > > > > I receive a large amount of JSON 'data' through AJAX from a > > > database > > > > (sorted the way I want viewed), and loop through them to > > > add to a JS > > > > string, and insert that chunk of string into a tbody of a > > > table. Then, > > > > I run a plug-in that formats the table (with pagination, etc.). > > > > Simplified sample code:
> > > > var html = ''; > > > > $.each(data, function(i, row) { > > > > html += '<tr><td>data from json</td></tr>';});
> > > > formatTable() requires that the table has to be "completed" > > > before it > > > > can be executed. > > > > Is there any way I can optimize this better? I think I've read > > > > somewhere that making a string too long is not good, > but I've also > > > > read that updating the DOM on each iteration is even worst.
> > > > Any advice would be appreciated!- Hide quoted text -
Rick, first you need to arrange your HTML to allow you to insert the entire <table> element in one fell swoop. IOW, put the table inside another container element that has nothing else in it, e.g.
<div id="scheduleContainer"> ... <table> and children will be inserted here ... </div>
Then your code might look something like:
function populateDutyTable(response) {
var currentDay = ''; var rows = response.QGETDUTYSCHEDULE.DATA; var out = [], o = -1;
In addition to the other optimizations I mentioned in my earlier message, I also combined consecutive string constants into one. You may prefer to keep them separate for readability and maintainability, at a slight cost in speed.
Mike, sorry if my post sounded like criticism - it was not intended
that way. However the representation of the test pages is misleading -
by accident I'm sure.
The majority of the performance difference between the 2 pages is
*solely* the difference between these 2 syntax....
The syntax differences above are responsible for 85% of the speed
difference between the pages - 7-times more than the loop-optimization
is. Yet none of the points you repeated above are related to this
issue. BOTH syntax only do a single DOM append - they just do it
differently. And the 'loop' is irrelevant to this 85% difference - a
simple string will still produce the same result.
If you replace the code in your 'slow page' with the sample I gave in
my last post - using .html( html ) - you'll see that the speed
improves 7-fold -- with no change to the string-concatenation loop or
anything else. Since this is 85% of the speed difference, this is
proper way to comparison of the issues you raised. (You could also use
$("<table></table>") in BOTH pages, but then the 'fast page' takes
over 7 seconds!)
So the loop-optimization produces only a 6-times speed improvement in
IE - not 30-times. This.is still a significant improvement by itself,
but I think it important to understand that $("<table></table>") is
*really* the big culprit here. In fact, I think this is something that
should be brought to the jQuery team's attention... Why is this syntax
so slower?
Ciao,
/Kevin
On Feb 7, 1:41 pm, "Michael Geary" <m...@mg.to> wrote:
> I never claimed that these pages reflect only the difference between the
> array join and string concatenation. On the contrary, in my other message in
> this thread I listed all of the factors that make the code faster:
> * Explicit for loop (and the fastest kind of for loop) - no function
> callback for each row.
> * Builds an array of string fragments and then joins it, instead of string
> concatenation.
> * Builds the array with "out[++o] = ..." instead of the more obvious
> "out.push(...)" (faster in IE).
> * Instead of inserting a large number of sibling DOM elements (the TRs)
> together, inserts only a single DOM element (the TABLE).
> Now it is very useful to know how much of the performance improvement is due
> to each of these individual tricks, and thank you for doing that testing. My
> purpose in posting was to combine all of the optimizations to create the
> fastest possible code.
> -Mike
> > From: Kevin Dalman
> > These test pages DO NOT accurately compare the speed of
> > array.join("") VS string+="...". The biggest speed difference
> > between the two is REALLY that one uses $("<table></table>")
> > and one doesn't. If this is removed from the 'slow' page, the
> > load-speed goes from 8.7 sec to 1.5 sec. This is still
> > 6-times longer than the fast version - but no longer 30-times longer!
> > Conversely, I changed the 'fast' page to use the append
> > syntax (after removing <table> and <tbody> from the array):
> > This changed the 'fast' load from 0.24 sec to 7.3 sec! So
> > even the 'fast loop' page performed 30-times slower when the
> > element-append method is used!
> > There was another code difference as well - the fast page uses $
> > ('#container').html() and the slow-page $('#container').append().
> > However, since the container is empty, it does not cause any
> > significant speed difference.
> > So for a TRUE loop-speed comparison, the code for the 'slow version'
> > should be:
> > var html = '<table><tbody>';
> > $.each( rows, function( iRow, row ) {
> > html += '<tr><td>' + row.text + '</td></tr>'; }); html +=
> > '</tbody></table>'; $('#container').html( html );
> > This now uses the same html() syntax as the fast version,
> > isolating the difference between the pages to ONLY the 2
> > loops. Now there is less than a 1.3 sec difference - instead
> > of 8+ seconds.
> > Now it becomes clear that the biggest lesson here is that append
> > ("<table<</table>") is a much bigger problem than the loop
> > code. This is important to know because it would apply even
> > if there were NO loop at all!
> > Thanks for bringing both these details to my attention. I do
> > a lot of dynamic HTML generation, so it's helpful to know
> > what to watch out for.
> > /Kevin
> > On Feb 5, 7:25 pm, "Michael Geary" <m...@mg.to> wrote:
> > > "...there is not much room for improvement left."
> > > You just know that when you say that, someone will come
> > along with a
> > > 20x-40x improvement. ;-)
> > > Try them in IE, where the performance is the worst and
> > matters the most.
> > > On my test machine, the first one runs about 6.3 seconds and the
> > > second one about 0.13 seconds.
> > > -Mike
> > > > From: Ricardo Tomasi
> > > > Concatenating into a string is already much faster than
> > appending in
> > > > each loop, there is not much room for improvement left.
> > What you can
> > > > do improve user experience though is split that into a recursive
> > > > function over a setTimeout, so that the browser doesn't
> > freeze and
> > > > you can display a nice loading animation.
> > > > On Feb 5, 5:03 pm, James <james.gp....@gmail.com> wrote:
> > > > > I need tips on optimizing a large DOM insert to lessen the
> > > > "freeze" on
> > > > > the browser.
> > > > > Scenario:
> > > > > I receive a large amount of JSON 'data' through AJAX from a
> > > > database
> > > > > (sorted the way I want viewed), and loop through them to
> > > > add to a JS
> > > > > string, and insert that chunk of string into a tbody of a
> > > > table. Then,
> > > > > I run a plug-in that formats the table (with pagination, etc.).
> > > > > Simplified sample code:
> > > > > var html = '';
> > > > > $.each(data, function(i, row) {
> > > > > html += '<tr><td>data from json</td></tr>';});
> > > > > formatTable() requires that the table has to be "completed"
> > > > before it
> > > > > can be executed.
> > > > > Is there any way I can optimize this better? I think I've read
> > > > > somewhere that making a string too long is not good,
> > but I've also
> > > > > read that updating the DOM on each iteration is even worst.
> > > > > Any advice would be appreciated!- Hide quoted text -
Hey, thanks Michael for taking the time to provide the explanation and the re-write. I'll put this into place and see how it performs. I'm sure it'll be *much* better!
> -----Original Message----- > From: jquery-en@googlegroups.com [mailto:jquery-en@googlegroups.com] On Behalf Of Michael Geary > Sent: Saturday, February 07, 2009 5:17 PM > To: jquery-en@googlegroups.com > Subject: [jQuery] Re: Optimize large DOM inserts
> Rick, first you need to arrange your HTML to allow you to insert the entire > <table> element in one fell swoop. IOW, put the table inside another > container element that has nothing else in it, e.g.
> <div id="scheduleContainer"> > ... <table> and children will be inserted here ... > </div>
> Then your code might look something like:
> function populateDutyTable(response) {
> var currentDay = ''; > var rows = response.QGETDUTYSCHEDULE.DATA; > var out = [], o = -1;
> In addition to the other optimizations I mentioned in my earlier message, I > also combined consecutive string constants into one. You may prefer to keep > them separate for readability and maintainability, at a slight cost in > speed.
> -Mike
> > From: Rick Faircloth
> > Hi, Mike, et al...
> > I'm having the same problem loading the DOM with a lot of > > generated HTML and I'm very interested in your approach to > > generating the code.
> > I looked over the example you have at ...loop2.html and have > > tried to modify it, but I'm afraid there's too much I don't > > understand.
> > My code works, but it's slow when loading the DOM making the > > browser to "freeze" and I'm afraid that will confuse the user.
> > If it's not too much trouble, would you consider modifying my > > code below to follow your pattern so I can see if it speeds > > up loading my DOM?
> > I would appreciate it very much, if you have the time or interest.
> > Rick
> > Here's my table building code:
> > function populateDutyTable(response) {
> > //First, empty table body of data > > $('#scheduleBody').empty(); > > currentDay = "";
> > //For each row within the query > > $.each(response.QGETDUTYSCHEDULE.DATA, function(i, row) {
> > if (currentDay != row[1]) { > > //Define a variable that will hold the html string > > var myRow1 = '<tr>';
I identified why the $("<table />").append syntax is so extremely slow
in the sample page. It actually has nothing to do with being a 'second
DOM append' as was assumed. Here is what I learned from my testing...
I generated the same 'html' var from Mike's test page - containing
2000 table-rows. The loop used is irrelevant to these tests because
the times shown below are for the DOM insertion *only*.
First, here is the original append-code from Mike's sample page...
Note the extreme slowness of the insertion - over 7 seconds!
But by just *moving* the <tbody> tags, it becomes 20-times faster...
$('#container').append(
$('<table></table>').append('<tbody>'+ html +'</tbody>')
);
// run-time: 0.36 sec
If we reduce it to a single command, it becomes 35-times faster...
$('#container').append(
'<table><tbody>'+ html +'</tbody></table>'
);
// run-time: 0.24 sec
BTW, the speed is the same whether .html() or .append() is used.
If the existing table is used instead, we gain only a few ms.
$('#Table').append('<tbody>'+ html +'</tbody>');
// run-time: 0.22 sec
To see if it makes a difference appending to a table that's 'not
empty', I appended the same 2000 rows *10-times* (to keep the math
simple)
html = '<tbody>'+ html +'</tbody>';
$('#Table')
.append( html )
.append( html )
.append( html )
.append( html )
.append( html )
.append( html )
.append( html )
.append( html )
.append( html )
.append( html )
;
// run-time: 2.23 sec
The run-time to append 10-times is *exactly* 10-times as long as
appending the first time. This means it makes no difference whether
the table is 'empty' or already has content.
So, in my tests, there is *no benefit* to appending an entire table to
an empty container. You get identical performance (in IE7) by
appending the new rows to a table - as long as they are wrapped in a
tbody. If the rows are not inside a tbody, then they are appended one-
by-one! This is why the syntax used by Mike was so extremely slow. It
actually had nothing to do with appending 2 elements, which I knew
could not account for a 3000% difference!
I dynamically generate table rows A LOT. My current web-app appends a
7-row tbody as a 'new record'. But I do not use loops to generate
html. Instead I use a hidden 'template tbody' that I clone. This has
all the events for the form-fields pre-attached. All I do is rename
all the fields after cloning the template, and before appending it to
the target table. This method is much easier to read and update than a
hundred lines of html-generating script. Plus I actually use the same
mark-up to generate the existing records onLoad (via JSP), so there is
zero code duplication.
I wanted to identify the cause of the slow append in Mike's sample
because I never see this in my applications. Now that I understand
what was happening, I see that appending a tbody is actually extremely
efficient - in fact, even faster than writing a new table! This is
good news because I cannot regenerate the entire table each time - I
must append new rows/records to an existing table.
I thought I'd share these results because appending a tbody (or a
single row) provides many more options than writing an entire table.
And now I know there is no performance difference - at least not in
IE7.
Thanks to Mike for providing a starting points for these tests, in
addition to his loop-optimization tips.
A container around the table is no longer required because wrapping
the rows in a tbody achieves the same performance as wrapping them in
a table. Plus, you could now add rows without regenerating the entire
table. This provides more options with no penalty. For example, now
you could hard-code the table with column headers - for example...
This is cleaner and faster than adding column headers inside your
Javascript loop.
I suggest you try both methods, Rick. Use a timer (like MIike's sample
pages) to confirm whether both are equally fast. Based on my tests,
you may find appending to the table even faster, with cleaner markup
as a bonus.
Ciao,
/Kevin
On Feb 7, 3:20 pm, "Rick Faircloth" <R...@WhiteStoneMedia.com> wrote:
> Hey, thanks Michael for taking the time to provide the
> explanation and the re-write. I'll put this into place
> and see how it performs. I'm sure it'll be *much* better!
|
