726340 - Make nsDOMEvent a skippable class

Status: RESOLVED WONTFIX

(Core :: DOM: Events, defect)

Description

[Andrew McCreight [:mccr8]]

With the patch from bug 726331, the purple buffer on TechCrunch is dominated by nsDOMEvent.  At least, from the CC gets triggered when I scroll down the page:
- On graph 3, 431 childless purple nsDOMEvents, out of 649 things in the purple buffer.
- On graph 4, 263 childless purple nsDOMEvents, out of 405 things in the purple buffer.
- On graph 5, 658 childless purple nsDOMEvents, out of 720 things in the purple buffer.

This will be trickier to fix, because nsDOMEvent has a number of fields and a number of subclasses.  Maybe this isn't worth doing.

Comment 1

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

Interesting. DOMEvents are usually kept alive only by JS.
But I don't know how to check blackness of a DOMEvent. They don't have a wrappercache.
Perhaps nsWrappedNative should be able remove objects from the purple buffer if the JS is black.

Comment 2

[Andrew McCreight [:mccr8]]

We don't need to check if it is alive, we can check if its children are all alive.  Assuming that isn't too expensive.  If all of its children are alive, then we don't need to visit it in the CC.

Comment 3

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

ah, very true, but tricky.

Comment 4

[Andrew McCreight [:mccr8]]

I should log info on what all of these childless events are, and why they have no children.  Maybe it is just something simple.

Comment 5

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

I would assume most of the events are mouse events (mousemove, mouseover, mouseout) and
event.*target point to some element in a in-CCgeneration document and event.view points to
a in-CCgeneration window object.

Comment 6

[Andrew McCreight [:mccr8]]

Makes sense.  When I madly scroll up and down there are about 1000 childless nsDOMEvents in the purple buffer, but maybe that's not a very useful scenario to optimize for.

Comment 7

[Andrew McCreight [:mccr8]]

I hacked up some code to print out what kind of event it is, just based on the split in the Traverse function.  It seems a roughly even mix of "other" (the default case), mouse and mouse scroll.

Comment 8

[Andrew McCreight [:mccr8]]

Probably not really needed any more given bug 728460.