On 3/29/14 8:23 PM, Patrick Walton wrote:
This is just 29 bytes of code when assembled. This is likely larger than
the equivalent `nsRuleNode`
The right comparison is not nsRuleNode but nsCSSSelector, right?
These are actually pretty bloated in Gecko right now. For example,
".foo #a" is parsed into a linked list of two nsCSSSelectors.
nsCSSSelector consists of 8 words and 8 more bytes, so 40 bytes on
32-bit and 72 bytes on 64-bit. So right now storing the parsed version
of ".foo #a" is 80 or 144 bytes in Gecko. This is not great, and we've
been talking about shrinking these for a while, but it's clearly not fatal.
The rest of your proposal seems pretty workable. The biggest issue, I
suspect, is a maintainability one: it forces a pretty tight coupling
between your selector jit and the object layout of your nodes, for any
of the tests performed directly in jitcode. For example, your cited
jitcode assumes that nodes have a "class" member and a "classCount"
member and that "class" points to an array of classes, right?
I think it should be possible to minimize the amount of coupling if it
turns out to be an issue in practice.
-Boris
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
