I used event delegation along with live() so it works on new elements
and it got rid of the leak!
Some good references for those who are interested:
http://www.learningjquery.com/2008/03/working-with-events-part-1
http://lab.distilldesign.com/event-delegation/
I've also wrapped the content into a <tbody> before appending (as
opposed to inserting into an existing <tbody>) and that shaved off a
couple of ms also. Sweet!
I'm learning more and more from this topic!
On Feb 7, 8:35 am, Ricardo Tomasi <ricardob...@gmail.com> wrote:
> 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:
>
> > > >http://blog.stevenlevithan.com/archives/faster-than-innerhtmlhttp://w......
>
> > > > 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!
>
>
