>Is the 'all nodes consuming same amount of memory' too much memory?
Unfortunately yes, this is a very big problem. This solution has been
discussed in the past, but some of the elements types necessarily contain
far more members than others, and this would absolutely destroy memory
usage in the face of competing browsers.
Cheers,
Josh
On 12 March 2014 05:24, Maciej Piechotka <uzytkown...@gmail.com> wrote:
> Recently I saw a video of person from scala team who regretted some
> 'pragmatic' choices in long run so I might be still under it's
> impression regarding pragmatic choices in a language. Fortunately (or
> unfortunately) I'm not in charge of Rust design.
>
> Also last question - why not use:
>
> struct Element {
> //... element specific elements
> }
>
> struct Attribute {
> //... attribute specific elements
> }
>
> enum NodeChild {
> NodeAttribute(Attribute),
> NodeElement(Element)
> }
>
> struct Node<'r> {
> parent: &'r Node,
> first_child: &'r Node,
> last_child: &'r Node,
> next_sibling: &'r Node,
> last_sibling: &'r Node,
> node: NodeChild
> }
>
> For static types:
>
> struct Element<'r> {
> elem: &'r Node
> }
>
> pub fn downcast_to_element<'r>(node: &'r Node) -> Option<Element<'r>> {
> match (node.node) {
> NodeElement(_) -> Some(Element {elem: node}),
> _ -> None
> }
> }
>
> + impl with potentially partial methods? Is the 'all nodes consuming
> same amount of memory' too much memory?
>
> 1. One word pointers - check
> 2. Access to fields - check
> 3. Downcasting and upcasting - check
> 4. Inheritance with prefix property - check (sort of)
> 5. No need for behind-the-back optimization - check
>
> -. static dispatch (check) at the cost of match instead of jump with all
> its pros and cons
>
> Best regards
>
> On Tue, 2014-03-11 at 19:47 -0700, Patrick Walton wrote:
> > I thought about tricks like this, but (a) a sufficiently smart
> > compiler should *not* be doing this automatically, as it makes certain
> > common operations like fetching the pointer more expensive as well as
> > violating the principle of least surprise when it comes to machine
> > representation, and (b) does this sort of hack really result in a
> > cleaner design than having some simple language extensions? Mind you,
> > I'm all about ways to simplify Rust, but sometimes the simplest
> > solution is to build stuff into the language.
> >
> > On March 11, 2014 7:39:30 PM PDT, Maciej Piechotka
> > <uzytkown...@gmail.com> wrote:
> > 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
> >
> >
> > ______________________________________________________________
> >
> > Rust-dev mailing list
> > Rust-dev@mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
> >
> >
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
