Hi James,

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.

by(e)
Stephan

2009/2/7 James <james.gp....@gmail.com>:
>
> 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:
>>
>> http://blog.stevenlevithan.com/archives/faster-than-innerhtmlhttp://www.bigdumbdev.com/2007/09/replacehtml-remove-insert-put-back-...
>>
>> cheers,
>> - ricardo
>>
>> 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. ;-)
>>
>> > >http://mg.to/test/loop1.html
>>
>> > >http://mg.to/test/loop2.html
>>
>> > > 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>';});
>>
>> > > > > $("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!
>>
>>

Reply via email to