Open Bug 686875 Opened 13 years ago Updated 2 years ago

SVG image doc uses too much style system memory

Categories

(Core :: CSS Parsing and Computation, defect)

defect

Tracking

()

People

(Reporter: khuey, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [MemShrink:P2])

1. Load https://tbpl.mozilla.org/images/closebutton-dark.svg
2. Check about:memory
3. See that this doc is using 600K of styledata memory.
Whiteboard: [MemShrink]
Is this with more reporters than there were about a week ago?  Because my opt build shows u using about 75KB on styledata on this SVG.  Which is similar to how much data we use for about:blank, unsurprisingly.  All of that is due to ua.css, of course.
This is with Tuesday's stock nightly which AFAIK has no new reporters.

I am on Windows ... if that might matter.
OK, just tried this in today's stock Mac nightly, with a clean profile.


│   └────108,224 B (00.18%) -- shell(https://tbpl.mozilla.org/images/closebutton-dark.svg)
│        ├───74,368 B (00.12%) -- styledata

Granted, on Mac, so in a 64-bit build.  I have a really hard time believing that we're really using 8-9x as much memory there in a Windows 32-bit build.

Just to make sure, this is a clean profile, no extensions, no huge userContent.css?
(In reply to Boris Zbarsky (:bz) from comment #3)
> Just to make sure, this is a clean profile, no extensions, no huge
> userContent.css?

No, it's not actually.  I can't reproduce this in a clean profile.
Alright!  So what's different about your profile?  This seems worth figuring out....
I have Adblock Plus installed.

Not sure what we can do here other than share stuff between documents or something similar.
The amount of memory used by styledata (as measured by our current reporter) essentially depends on the number of selectors used in the stylesheets....  So yeah, either fewer selectors or more sharing of some sort.  This last is complicated by the fact that the cascade really does need to be different for different documents, in general.
Which selectors count here? I guess that selectors in @-moz-document limited to another domain don't count? If so, we are currently talking about roughly 4500 selectors in EasyList. Unfortunately, finding the ones that are no longer useful is non-trivial. A solution is planned but might take a while to implement.
> I guess that selectors in @-moz-document limited to another domain don't count?

I believe that is correct.
Whiteboard: [MemShrink] → [MemShrink:P3]
Blocks: 999931
Whiteboard: [MemShrink:P3] → [MemShrink:P2]
Depends on: 1008455
Depends on: 1011802
Depends on: 1011806
Depends on: 1013936
No longer depends on: 1011802
Depends on: 1015147
Blocks: 1054016
No longer blocks: 1347543
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.