Open Bug 764899 Opened 12 years ago Updated 2 years ago

Add skippable optimizations for SVG elements

Categories

(Core :: Cycle Collector, defect)

defect

Tracking

()

People

(Reporter: mccr8, Assigned: smaug)

References

(Blocks 1 open bug, )

Details

I get long CC times on this page, after I've interacted with it a bit. The slow CC times don't show up right away. They are around 200-300ms.
Sorry, around 120ms. Leaving the browser idle for 20 or so seconds was enough to cause the CC times to go bad.
Assignee: nobody → continuation
Categories of nodes with > 200 members: 43503 JS Object 5716 nsGenericElement (SVG) rect http://v6launch.ripe.net/cgi-bin/http.cgi?embedded=1 1293 JS Script 815 XPCWrappedNative 665 nsXPCWrappedJS 559 nsGenericElement (XUL) 245 nsXULPrototypeNode 206 nsGenericElement (SVG) text http://v6launch.ripe.net/cgi-bin/http.cgi?embedded=1
I checked a few of the SVG elements, and they all have preserved wrappers, and nothing else besides their wrapper referring to them, so I think the problem here is just that SVG elements need to have better support for CC skippable optimizations. I just need to figure out where there traverse is implemented.
Blocks: 716598
Summary: Long CC times on http://v6launch.ripe.net/cgi-bin/index.cgi → Add skippable optimizations for SVG elements
There are a ton of fields named "raphael" which Ms2ger points out probably indicates this is using the Raphael.js library. http://raphaeljs.com/
Well, at least they get nsGenericElement's traverse. But do the SVG elements own other stuff?
They don't seem to. Their only field in the graph is the preserved wrapper. Maybe the problem is they aren't being detected as live correctly? Do SVG elements live in a different kind of document or something?
I don't really have time to look at this right now. As Olli points out, this should be covered by the standard element optimizations. It also doesn't happen immediately, so there may be some weird thing that is happening. To reproduce, just leave the URL open for a while. Sometimes it happens quickly, sometimes it takes a long time. Probably the next step is to look at a WantAllTraces dump when the CCs are slow, to try to figure out what is keeping these SVG elements alive, and figure out why they aren't being optimized out. It seems like the problem is that the unmarkgray isn't happening on their wrappers, but I don't know why that would be.
Assignee: continuation → nobody
I can try to look at this, tomorrow or next week.
Assignee: nobody → bugs
(In reply to Andrew McCreight [:mccr8] from comment #6) > Do SVG elements live in a different kind of document or something? No, they don't.
Severity: normal → S3
Component: XPCOM → Cycle Collector
You need to log in before you can comment on or make changes to this bug.