Comments on: replaceHTML for when innerHTML dogs you down

By: Robert

Robert — Sat, 15 Sep 2007 00:50:34 +0000

“Performance” would be a nice tag – so we could easily find this post later ;-)

By: Tom

Tom — Fri, 14 Sep 2007 18:05:25 +0000

About benchamrking,
maybe someone could take the trouble of looking up DOMs in popular apps like Gmail, google docs, Windows Live, sites with YUI, ZK and GWT, and scriptaculous-based and come up with a sort of report on the amount of elements of each type that you would habdle in a “typical web2.0″ site. obviously one number, or a few, is useless.
So we could say that something like this is useful:
No. of divs, tables, td’s, tr’s,
level1, level2, level3 span’s, div’s,
elements with heavy css styling: 4-5 rules per element,
elements with minial styling: 1or 2 css rules
inherited rules, inline styles

Kinda like saying you *become* the browser and its DOM and then analyse everything in it from a benchmarking perspective.
Much like any other decently acceptable benchmarking system.

Anyone game?
PS: If you’re that confident about the quality of such a test that you perform, and document, you could sell the whitepaper ;-)

By: Marty

Marty — Fri, 14 Sep 2007 13:02:07 +0000

Anon: the question is: who in real life needs 1000+ innerHTMLs in a row?

I do. Next question.

By: Gorm

Gorm — Fri, 14 Sep 2007 09:00:38 +0000

@Steven Levithan
I get slower results with the new Opera alpha from time to time. Actually it’s faster sometimes, but slower other times (not by any noteable margin though). My point is that you don’t know if the browser will change it’s implementation in the future. I would rather see vendors fix/optimize rather than doing unpredictable hacks.

By: Vital

Vital — Fri, 14 Sep 2007 08:40:02 +0000

i don’t know, what a computer do you have but for me, replaceHtml ALWAYS slower than innerHTML (Opera 9.23, FF 2.0.0.6, IE 6, Safari 2.0.4)

By: Steven Levithan

Steven Levithan — Fri, 14 Sep 2007 06:43:26 +0000

@deadcabbit: Alas, it’s often the case that such is life in the world of cross-browser JavaScript performance testing, especially if you or your OS have a lot going on in the background. Also note that many people give too much weight to (often meaningless) averages of repeated tests. The numbers I posted are based on best times for each discrete test on my personal system over numerous run-throughs. IE performance times are typically so fast that minor differences can seem significant if you only look at the comparison calculations. If you look at the code, you will will see that it cannot possibly be faster than simple use of innerHTML in IE, since that’s exactly what’s used in that browser.

By: deadcabbit

deadcabbit — Fri, 14 Sep 2007 05:45:15 +0000

No matter how hard I try, the results are unreliable or unsatisfying. Opera on my Vista home fluctutes weirdly and IE7 always seems to be slower.

By: Charles

Charles — Thu, 13 Sep 2007 23:00:03 +0000

OT: I second Matt’s motion for tagging, I swear I just had a similar thought 30 seconds ago.

By: Steven Levithan

Steven Levithan — Thu, 13 Sep 2007 22:05:25 +0000

Yes, and I’m sorry if I contributed towards turning this into a somewhat heated discussion. As noted in the parallel discussion with Brewer on my blog, his approach has less potential for unexpected side effects, so it is preferable for things like JavaScript frameworks.

By: Kris Zyp

Kris Zyp — Thu, 13 Sep 2007 21:35:04 +0000

It should be pretty clear which approach to use. If you possibly have references to the element in question, than use Brewer’s, if not you can use Levithan’s.

By: anonymous

anonymous — Thu, 13 Sep 2007 21:31:48 +0000

the question is: who in real life needs 1000+ innerHTMLs in a row?

By: Steven Levithan

Steven Levithan — Thu, 13 Sep 2007 19:55:42 +0000

“didnâ€™t escape my HTML in blogger – Iâ€™ve updated” –Steve Brewer

Gotcha. As for, “Youâ€™ll have to demonstrate…”, see here: http://stevenlevithan.com/demo/replaceHtml2.html

At least on my system, withRemove() is consistently slower in all of the four big browsers.

By: Matt

Matt — Thu, 13 Sep 2007 19:11:17 +0000

Dion, et al,

You guys should either a) Have a “performance” category that you tag articles with, and/or b) enable user tagging

Either way, it’d be great to come back to Ajaxian.com when I need to do some performance improvements, and find articles like this easily.

Thanks!!

- Matt

By: Steve Brewer

Steve Brewer — Thu, 13 Sep 2007 19:02:43 +0000

Hey Steve,
My test used 15,000 spans, not one text node (didn’t escape my HTML in blogger – I’ve updated).

The perf gain is about manipulating a node that’s in the DOM vs. one that isn’t. This is a common performance trick (see Y!’s performance blog).

You’ll have to demonstrate “The destroy step is slower”. If you’re replacing a big chunck of HTML with another big chunk of HTML, your function and remove-update-replace are pretty much equal speed wise – except replaceHtml has gone and blow away the original node.

By: Japayth

Japayth — Thu, 13 Sep 2007 18:56:43 +0000

You should probably run a “for (attr in node)” to preserve other attributes, not just the id.

By: Steven Levithan

Steven Levithan — Thu, 13 Sep 2007 17:45:24 +0000

@Brad Harris: This function is not appropriate if you need to worry about cross-browser memory leak issues resulting from event listeners on child nodes, etc. However, the overhead of dealing with such issues when you don’t need to (which many frameworks do for you… e.g., with jQuery.html(value), etc.) can be just as much if not more of a problem.

@Steve Brewer:
I hope you realize that your currently posted test (which builds a single textNode consisting of the string “CONTENT” repeated 15,000 times) is not remotely comparable. The approach you describe is certainly faster than plain innerHTML, at least in Firefox, but it is not faster than replaceHtml (it is easily demonstrable that the “destroy” step is slower).

@Fabian Jakobs:
That is very interesting! In fact, upon initial tests, it appears that simply wrapping the new html string in a

element before using innerHTML is a very effective solution against the performance issues in both Firefox and Safari!

By: Andy

Andy — Thu, 13 Sep 2007 17:05:56 +0000

Can we have “Email Article” on this site? I wanna email this article to my friend since he’s an Ajax developer but I have to manually copy and paste the URL. I thought “Email Article” is already a standard feature nowadays.

Just my 2 cents.

By: Fabian Jakobs

Fabian Jakobs — Thu, 13 Sep 2007 16:23:42 +0000

Nice code. I thought I could speed up our virtual table with this hack but it seems that it only has this speed improvements if the parent element really has many child nodes. If you put a single div around the test string the speed improvement drops to just 1.3x no matter how many elements are inside this div.

In our case the parent element would only have one single child, the table, which is regenerated using innerHTML and this hack does not help us much :-(

By: Steve Brewer

Steve Brewer — Thu, 13 Sep 2007 16:21:47 +0000

It’s faster because updating a node that isn’t in the DOM is a lot faster than doing the same on a node that is in the page. Creating a new node isn’t needed – take the node out, update it, and put the original node back in – it will give you the same results without invalidating existing references to you node. I wrote it up on my blog: http://www.bigdumbdev.com/2007/09/replacehtml-remove-insert-put-back-is.html

By: Steven Levithan

Steven Levithan — Thu, 13 Sep 2007 15:54:29 +0000

@Gorm, the only browser it is always slower in is IE (and only by a narrow margin, which is easily avoidable using conditional compilation). Performance improvements comparable to those in Firefox can also be seen in Safari 3.0.3 beta. Luca’s numbers for Opera are clearly a case of background interference, since the length of the “destroy & create” test should not be much different than the length of the “destroy only” and “create only” tests added together.

If and when Firefox and Safari improve/fix the related issues, obviously this would have little benefit. Until then, it can make the difference between a “broken” application and blazing performance (or perhaps a less dramatic but still positive change in other apps).