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!
>
>
