On 4/23/14, 7:38 PM, Keegan McAllister wrote:
* How much does a 128-bit compare cost, vs. 64 bits for a pointer?
Are we more or less assuming we're on 64-bit systems?
My memory is that the 128-bit IID compares we end up doing in
QueryInterface sorta suck, but we do a bunch of them at a time, which
can't help....
Measuring is probably the right plan here, but need to make sure to do
it on a variety of hardware.
* How much does bloating the DOM cost, in terms of memory usage and cache
pressure?
Note that in Gecko the DOM does not store too much in the way of atoms.
For example, element tag names are stored in nodeinfo structs (shared
across all elements with the same document/localname/namespace/prefix),
not in the element themselves.
We do store an atom-or-nodeinfo in nsAttrName in Gecko to avoid the
extra indirection in the super-common case of an attribute in the null
namespace, but obviously one could always use nodeinfo here.
So I suspect memory usage is not a huge issue in practice.
Cache pressure is a much bigger deal, unfortunately. Selector matching
in particular is not all that cache-friendly in Gecko....
* Can we make the cryptographic hash fast enough?
We should see how often we end up atomizing things that are over 16 chars.
I guess a fairly large number of IDs and classes might in fact be there...
-Boris
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
