62897 - Style Rules take up too much memory - look into making them smaller

Status: VERIFIED WONTFIX

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Marc Attinasi]

Next to Style Contexts, the style rules, as represented by the classes
CSSDeclarationImpl, CSSStyleRuleImpl and nsCSSSelector, are the next largest
data structures in the style system. We should investigate to see if we can
reduce the amount of memory that the rules require.

Comment 1

[Hixie (not reading bugmail)]

potential embedding requirement?

Comment 2

[Marc Attinasi]

So, it turns out that the code that dumps the sizes of nsCSSDeclaration and 
nsCSSSelector is wrong: it is counting each atom instance as its own memory. 
Instead, I need to modify it so that shared atoms are only counted once, and I 
think that the size of teh style rules will seem much more reasonable. At least 
I hope so, because I cannot find anything to trim off of them!

Comment 3

[Marc Attinasi]

Fixing the multiple-counting of shared atoms does not really change the numbers
much - for viewer test0.html it only takes off about 1.5KB.

I have found some potential _under_ counting in nsCSSDeclaration too: currently
we just do a sizeof() on the declaration data structures, like nsCSSFont,
nsCSSFont etc, but that is only correct when they do not contain string values.
The class nsCSSValue really should get a SizeOf method so that it can count up
the strings that are attached to some of the values too (nsCSSValue is basically
a union of Int, Float, String, Color values).

Since nsCSSDeclarations are already reported as taking up loads of memory (next
to style contexts they are the highest users of memory in style), and we are
undercounting their real memory impact, there is a need to focus on them a bit more.

Comment 4

[Hixie (not reading bugmail)]

Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...

Comment 5

[karnaze (gone)]

Moving to m1.2

Comment 6

[Pierre Saslawsky]

Bug 78695 made this one obsolete.

Comment 7

[Hixie (not reading bugmail)]

rubberstamp verify