Speed up ChangeDocumentFor a bit

RESOLVED DUPLICATE of bug 564591

Status

()

Core
XBL
RESOLVED DUPLICATE of bug 564591
8 years ago
8 years ago

People

(Reporter: bz, Assigned: bz)

Tracking

(Blocks: 1 bug, {perf})

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Created attachment 444235 [details] [diff] [review]
Simple change

Ran into this while profiling the testcase in bug 564575.  The hashtable ops in ChangeDocumentFor hurt us.  I _think_ we can skip at least some of them.

I'm pretty sure about the SetAnonymousNodesFor being conditioned on |binding|.  What about the SetContentListFor change?  Is that ok?  The NODE_IS_INSERTION_PARENT flag is sadly underdocumented.  And do we need that SetInsertionParent call?  Either the node is being removed directly (and then ContentRemoved did the SetInsertionParent), or some ancestor is being removed, and then presumably the relevant bindings are being nuked and hence the insertion parent table will be updated correctly... right?
Attachment #444235 - Flags: feedback?(jonas)
Attachment #444235 - Flags: feedback?(Olli.Pettay)
I have a better patch for this that seems to work. I've been whacking our BindToTree/UnbindFromTree code fairly hard. Will attach patches once the last of them are done.
Oh?  I'd been glaring at our bind/unbind code, but not quite willing to spend enough time today to really take it apart.  Are your patches available somewhere so I can profile/test with them?  Is there a bug to follow?
Indeed.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 564591
Attachment #444235 - Flags: feedback?(jonas)
Attachment #444235 - Flags: feedback?(Olli.Pettay)
You need to log in before you can comment on or make changes to this bug.