If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Enjoy an ad free experience by logging in. Not a member yet? Register.

2) It seems like the .htc - or the script inside the .htc - has to be parsed every time an element is bound. IE creates an additional JScript engine for the .htc instead of using the main one. I don't know if it creates the JScript engine for every bound element instead of sharing it for all bound elements, but if it did, that would be even worse.http://blogs.msdn.com/ericlippert/ar.../04/67525.aspx

(note: I'm not sure if its the HTC aspect of it being slow or the script itself, since the HTC is applied only to the body element)

3) They can cause a memory leak until the page is refreshed or directed to another page. Specifically, IE doesn't deallocate memory when a behavior is dynamically removed, which means it can happen when the bound element is removed. Thus, pages that are dynamically changed a lot will start hogging up more and more memory.

From http://msdn.microsoft.com/workshop/a...owto/using.asp:
Note A behavior attached to an element through CSS, using a style rule defined in the document, is automatically detached from the element as soon as the element is removed from the document tree. Once the element is removed, all associations of that element to any element in the document tree, such as style sheet rules that specify behaviors, are stripped from the element as well. On the other hand, a behavior attached to an element through an inline style, or through the addBehavior method, is not automatically detached from the element when the element is removed from the document hierarchy. These two methods of applying behaviors have no dependencies on the containing document, and therefore the behavior remains applied to the element even as it is removed from the document tree. The removeBehavior method can be invoked to explicitly detach this type of behavior from the element.

to fix issue 1. On this 1.6Ghz Pentium M laptop, the page took ~1.5 seconds to load (and reload) and during that time IE was unresponsive.

Another test: I saved this page (newthread.php) as an htm, which has around 650 elements in the body, added the behavior code, and loaded (and reloaded) it up in IE: took ~3 seconds to load.

Then I tested a much lighter HTC: DOM2 event support on the same page (newthread.php). With the HTC: ~600ms. Without the HTC: ~250ms. That's more reasonable, but still bad.

During all this testing, I noticed another large problem: unloading the page takes much much longer and the browser is also unresponsive around this time. For newthread.php and the DOM2 support HTC, it took around 1 sec to unload. Unfortunately, this lag occurs after the window unload event, so I couldn't accurately time it.

Now I test it on a copy of the JavaScript forum listing (forumdisplay.php), which has around 1100 elements in the body. With the DOM2 support HTC: ~800ms to load, ~3 secs to unload. Without the HTC: ~420ms to load, nearly instantaneous unload.

So is there any way to improve the performance of HTCs, especially when applied to many elements?

Probably not without a lot of careful engineering (for lack of a better term). Isolating a problem during construction is most always less involved than diagnosing a set of interdependencies. (I don't really know what I'm trying to say, except take it one step at a time... if someone else's code is the problem, then start over).

As the author of those HTC's, I must explain a little about what is going on. The prototyping HTC is *very* expensive, and not because it is an HTC. To fake the inheritance, I actually dump the entire prototype each time an element is bound. Say we have n properties/methods in the prototype, and m elements to bind. Then we have O(n*m) performance hit. It's more an academic exercise than a useful one.

The DOM2 Event HTC, however, simply adds 2 methods to each element. It takes O(1) to assign a new method, and so we only have an O(m) performance hit. It's also declared not to have ViewLink content, so I assume IE makes optimizations to it.

Whatever overhead caused by the HTC's is made insignificant by the massive inefficiency of the psuedo-prototyping method. Not that it can be done much better. A possible optimization is taking a static "screenshot" of the prototype. If you're not extending at runtime, then after your initial prototypes are set, you can removeBehavior from each of the elements in the page, and the prototype assignment should still remain.

The disadvantages is that the script is delayed until the window.onload and that new elements won't support the new methods. The latter point can be solved by replacing document.createElement and each element's cloneNode with functions that would fix the new element(s) up, but that would I suspect that would make the script at least twice as slow, and the new createElement and cloneNode methods would be slightly slower than the original ones.

In any case, here are the results for a copy of the JavaScript forum listing (forumdisplay.php):

With above script: ~570 ms load, near instantaneous unload

With HTC: ~760 ms load, 3-4 sec unload

Without script/HTC: ~440 ms load, near instantaneous unload

So the HTC is significantly slower than the script (though if the script included the modified createElement and cloneNode, this might not be the case) when loading the document. However, the biggest problem for HTCs is apparently the unload performance.