On 5/29/14, 11:39 AM, Simon Sapin wrote:
I’m aware that every style struct must contain either only inherited properties, or only reset (non-inherited properties). Other than that, what’s the guiding principle to decide how many structs to have, and which properties go where?
Initially the idea was to group properties that are likely to be set together into structs (because then setting them will allocate the smallest number of things possible). Also, color was its own struct to ensure that it could be cached in the ruletree (since it's an inherited property, adding more props to the struct would make it very unlikely this could happen).
Since then people have been adding things somewhat willy-nilly. I've claimed for several years now that we should reevaluate how we store this stuff in Gecko.
> Why not have every longhand property in its
own "struct", sharable separately?
Keep in mind that we're talking about computed style. That means you need values for all longhands.
Right now a style context has to point to 20-ish structs, so ends up with 20 words worth of pointers in it (except in cases where we optimize out not having any reset structs in the style context itself).
If we had to separately point to each longhand's value, a style context would have several hundred words of pointers in it.
So that's the main guiding principle to deciding how many structs to have: too many and you need too much memory to keep track of them; too few and you have no meaningful sharing.
In Gecko, additionally, computing a struct has some constant overhead (walking over the rule tree) and hence structs that are too fine-grained have too much computational overhead. This is one reason we put all the things typically needed to construct a frame in the Display struct, by the way...
Is there something you’d like to change in Gecko’s distribution, but don’t because making the change would be too painful?
The primary question is what the distribution should be. If the original goals are maintained, that involves measuring which properties are set most and which are correlated with which other ones, basically.
For other approaches, at one point WebKit had something like these structs, but fewer and smaller, with a big "rare data" struct. That has some obvious drawbacks too, if you guess wrong on what's rare (or it changes).
In general, it's not clear to me what the "right" storage setup is for computed style.
-Boris _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
