944192 - Optimize out common cases when calling nsContentList::ContentAppended

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

Attachment: optimize_out_common_contentlist_append.diff

This gives 65x speed up (ops/js) in js only case and 8x in jQuery case of Bug 944127.
(We're trying to match applet and form contentlists most of the time!)

I'm looking at various things to optimize here,  this is the initial simple case.

Comment 1

[Boris Zbarsky [:bzbarsky]]

> (We're trying to match applet and form contentlists most of the time!)

Hmm.  I wonder whether some of those rarely-used lists should in fact have a flag to go lazy faster.

I also wonder why those are even touched on the jsperf page...

An interesting question: did those have a JS wrapper when we tried to match them?  If not, maybe we could even use _that_ as a signal that no one cares about the list and hence it should go lazy.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Another interesting possibility is to simply special-case document.forms and document.applets and make the relevant tags explicitly add/remove themselves on bind/unbind instead of using a generic live list for them.  We should seriously consider that.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8339634 [details] [diff] [review]
optimize_out_common_contentlist_append.diff

This is OK, but common wisdom is to build up a DOM tree and insert it at once, so for everything except silly microbenchmarks this won't win us much. We should seriously consider some of the other suggestions here.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

(In reply to Boris Zbarsky [:bz] from comment #1) 
> An interesting question: did those have a JS wrapper when we tried to match
> them?  If not, maybe we could even use _that_ as a signal that no one cares
> about the list and hence it should go lazy.

That I like.

But given the current setup in nsContentList::ContentAppended, that wouldn't help us with the test.
We're doing tons of appends, and nsContentUtils::PositionIsBefore can't handle them efficiently.
Lazyness check is afterwards.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/026aec496a07

Comment 6

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/026aec496a07