The testcase shows that we do too many addrefs/releases (partly because of bug 355221, which I hope we could back out now) and HTML's contentEditable code could be faster.

This reduces Addref/Release significantly and speeds up bindToTree perf up to 10%.

Don't we need to make absolutely sure all instances of script running under BindToTree are fixed first? That includes anything that could spin an event loop (e.g. iframes).

That is why I started to add bugs to "depends on" -field.

Comment on attachment 351229 [details] [diff] [review] nsCOMPtr<nsIContent> -> nsIContent* I think we could take this to trunk now.

Is that comment about removing still valid? I assume we're relying on extensions not touching the DOM here, right? Because extension JS can certainly run under BindToTree... :( _if_ we can really rely on no one touching the DOM while we do these loops, we could use GetChildArray for another possible performance boost (though we already avoid the virtual function call overhead, I guess). But that approach would be _really_ bad if someone's touching the DOM... Then again, so is removing the strong refs. :(

(In reply to comment #6) > I assume we're relying on extensions not touching the DOM here, right? Because > extension JS can certainly run under BindToTree... :( You mean content policies or such? If yes, I guess those should be postponed using script runner... The comment is valid if extensions don't do anything evil :/

I mean content policies (which cannot be postponed unless we postpone the load as a whole). I also mean necko notification listeners (fired synchronously as necko learns about the loads). Perhaps we should simply move all network access out from under BindToTree and AttributeChanged into script runners... I assume you meant the comment is _invalid_ if extensions don't do anything evil? It says the node can remove itself; I don't see how it could. Note that "evil" for purposes of this code means mutating any part of any DOM, not just of the DOM we're working on here.

(In reply to comment #8) > I assume you meant the comment is _invalid_ if extensions don't do anything > evil? Oops, right.

Bug 490695 should speed up things a bit.