1376936 - nsContentLists should stop observing mutations when their refcnt drops to 0

Status: RESOLVED FIXED

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

Description

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

nsContentLists should stop observing mutations when their refcnt drops to 0.
This way they wouldn't affect DOM mutation performance while waiting to be deleted.

Comment 1

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

Attachment: contentlist_last_release.diff

remote: Follow the progress of your build on Treeherder:
remote:   https://treeherder.mozilla.org/#/jobs?repo=try&revision=081c51f7e00853fc4e8880893cff60e42d804a12
remote: recorded changegroup in replication log in 0.115s

Comment 2

[(no longer active)]

Comment on attachment 8881975 [details] [diff] [review]
contentlist_last_release.diff

Review of attachment 8881975 [details] [diff] [review]:
-----------------------------------------------------------------

We do something very similar in nsContentList::NodeWillBeDestroyed() and it would be nice to share code.  It seems like since we're basically not going to get any new notifications in that case, we can have that function call LastRelease() directly.  If you agree, please consider making that change.

Thanks!

Comment 3

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

I was thinking that... 
though, ok, I could add a helper.

Comment 4

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

Attachment: contentlist_last_release_2.diff

Comment 5

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

er, we don't want to call RemoveMutationObserver in NodeWillBeDestroyed.
I think it is good enough to keep those methods close enough.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/0cec50535e2c
nsContentLists should stop observing mutations when their refcnt drops to 0, r=ehsan

Comment 7

[(no longer active)]

Oh right there may be notifications for other nodes...  I was confused, sorry about that!

Comment 8

[(no longer active)]

This is a profile after this patch: http://bit.ly/2tox8YY

Compare to a profile before from bug 1376936: http://bit.ly/2s0sgFB

This has cut down the cost of MatchNameAttribute roughly by about half in this profile it seems!

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/0cec50535e2c