Re: [dev-servo] Meeting 2013-11-04: mac builder failure, priorities (C++, layout, parallelism, rustpkg, embedding, graphics)
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. 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. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting 2013-11-04: mac builder failure, priorities (C++, layout, parallelism, rustpkg, embedding, graphics)
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
