On Tue, 2014-03-11 at 14:18 -0700, Patrick Walton wrote: > On 3/11/14 2:15 PM, Maciej Piechotka wrote: > > Could you elaborate on DOM? I saw it referred a few times but I haven't > > seen any details. I wrote simple bindings to libxml2 dom > > (https://github.com/uzytkownik/xml-rs - warning - I wrote it while I was > > learning ruby) and I don't think there was a problem of OO - main > > problem was mapping libxml memory management and rust's one [I gave up > > with namespaces but with native rust dom implementation it would be > > possible to solve in nicer way]. Of course - I might've been at too > > early stage. > > You need: > > 1. One-word pointers to each DOM node, not two. Every DOM node has 5 > pointers inside (parent, first child, last child, next sibling, previous > sibling). Using trait objects would 10 words, not 5 words, and would > constitute a large memory regression over current browser engines. > > 2. Access to fields common to every instance of a trait without virtual > dispatch. Otherwise the browser will be at a significant performance > disadvantage relative to other engines. > > 3. Downcasting and upcasting. > > 4. Inheritance with the prefix property, to allow for (2). > > If anyone has alternative proposals that handle these constraints that > are more orthogonal and are pleasant to use, then I'm happy to hear > them. I'm just saying that dismissing the feature out of hand is not > productive. > > Patrick > >
Ok. I see where my misunderstanding was - I was thinking about DOM
implementation in Ruby for Ruby while you (Mozilla) were talking about
implementation in Ruby for JavaScript.
Please feel free to ignore next paragraph as I haven't given it much
though but my guess would be that it would be possible to avoid the
penalty by enum + alignment + smart compiler. As data have 6 words + in
your scheme (5 described + vtable) the 4 bit alignment (assuming 32+ bit
platform) should not cause much memory waste. This allows for using the
'wasted' bits for other purposes (the trick is used in, for example,
lock-free structures) - for example:
enum ElementChild<'r> {
ElementChildElement(&'r Element),
ElementChildComment(&'r Comment),
}
Could be represented as pointer with last bit specifying if it's element
or comment - similar to Option<&T> optimization. The lookup should
behave much nicer with respect to branch prediction (plus) but getting
pointer is more complicated (minus) and possibly longer code instead of
jump (minus). If data alignes the compiler should be able to optimize
the jumps if it notices that all jumps lead to the same pointer
arithmetic. I'm not sure about handles from JS but I don't think there
is more then 16 choices for types of parent/child/sibling for any node
so it should be achivable - on language side it would just be enum +
pointer (+ specification of alignment as attribute?).
That said a) I have done no measurements/benchmarks so my intuition is
likely to be wrong b) should in above paragraph means 'it looks that it
could work after 5s thought' and c) I'm not a Rust designer and I don't
pay for nor contribute so I don't expect that I should have anything
resembling last word.
Best regards
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
