On 4/28/14, 6:02 PM, Keegan McAllister wrote:
Ultimately I'm sort of pessimistic about table-less interning, because it
proposes to speed up parsing at the expense of layout.
A thought.
If the goal is to speed up parsing in a separate task by avoiding
contention on a table, have we considered a setup where we do part of
the work of interning (e.g. computing the hashcode) in the parsing task
but then leaving things in that state and finishing up the interning
when we ship the data from the parsing task to the task that ends up
using the data?
This is similar to the approach the JS engine is using for its
off-main-thread parsing in Gecko: there's a fixup step when the parsed
representation is shipped back to the thread that requested the parse.
One issue there is that layout and dom might to share the table,
depending on where we do the "finish up" step of CSS parsing. Is the
plan for that to be in the layout task or the DOM task, or sometimes one
and sometimes the other?
Storing small strings immediate and using a table for the rest seems promising,
though.
Agreed.
I also liked the idea of using Gecko to gather information about interned
strings.
I'm happy to write up some patches here if people know what info we want
to gather.
-Boris
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
