On 11/5/13 2:11 PM, Robert O'Callahan wrote:
I had a discussion with pcwalton and kmc yesterday about string interning.
The concurrent cuckoo hash table is cool but maybe not the right fit for
the browser workload for a couple of reasons:
a) interning lookups are mostly not on the hottest paths. They will occur
during parsing, and that can mostly happen off the main thread. Parsing
selectors for querySelectorAll etc would happen on the main thread (or at
least synchronously with it), but we cache parsed selectors in Gecko anyway
(as of recently). Also, we have the option of wrapping a thread-local cache
around the global intern table.
b) it's important to efficiently resize the table and shrink it by removing
unused atoms. That may not be easy to add to the concurrent cuckoo table.
Agreed. Also:
(c) We aren't really interested in a hash *table*, more of a hash *set*.
So lookup speed of *values* doesn't actually seem to me to matter much.
Regarding new layout features, I think it's important to tackle some
architectural issues before adding more features:
-- Bidi and vertical text
-- Fragmentation (page/column/overflow:fragments breaking)
The former introduces abstractions that will be easier to introduce now
than any time in the future, since all your layout features will build on
them. The latter is a big architectural thing that will also be easier to
introduce now than in the future, and also may impact your design in
fundamental ways.
I think I have a handle on what needs to be done for the former, but the
latter is a bit opaque to me. Maybe a tutorial on what we need to watch
out for would be helpful :) I don't want to take up too much of
your/dbaron's time, but it'd be great to know what we need to watch out
for to avoid baking in bad assumptions.
Patrick
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
