On 2/14/13 1:52 AM, Patrick Walton wrote:
Currently, floats aren't really on our priority list; we want them to be
done, but other things are higher priority. For example, the scheduler
rewrite. :)
OK, good. That was non-obvious from the mail that started this thread. ;)
This has the problem that there are two allocations (one for the handle)
and two levels of indirection for each property access. Moreover, these
costs are paid even in the sequential case, when layout is not running:
Indeed. The separate allocations is in some ways a bigger issue than
the indirection. At least if we assume we don't get too many cache
misses, which may be a bad assumption.
(3)
....
The disadvantage is that sets are slow, because they
involve copying the DOM node and allocation.
Only sets on clean nodes are slow, right? Once you've set something,
you just keep writing to the already-allocated bit.
Which means for microbenchmarks (which is where the access cost of
primitive gets/sets is really most critical) we should be able to do ok
with this approach. Even for real-life things, I think...
This still has an extra branch on gets/sets, but that might well be ok.
It's certainly worth at least prototyping this out to measure the
performance. I definitely like this more than (2): it seems way simpler.
Niko and I have a proposal and we can bring it up at the next Rust
meeting on Tuesday.
Please?
and implement the DOM object methods
that have to be virtual using unsafe Rust code.
You mean non-virtual, right?
I mean virtual. Right now virtual in Rust is all-or-nothing; all your
methods are virtual or none are. As I understand things, however, the
DOM needs a finer-grained approach, in which some methods are virtual,
some methods are nonvirtual, and some fields can be accessed at known
offsets. So for now we can use structs that Rust already provides, which
provide both nonvirtual methods and fields at known offsets out of the
box, and then craft vtables out of unsafe code
Aha, I see. I just had it backwards, which explains the rest of my
confusion here.
This should work pretty well, actually: not that much DOM stuff needs to
be virtual in practice. I just checked, and .nodeValue is the only
virtual Node method in Gecko's WebIDL bindings. And on Element it looks
like only the UndoManager stuff and .innerHTML are virtual.
And for non-Node things I assume if we want to we can in fact use the
all-virtual setup for cases that really need it, if any.
You can always simulate simple stuff like tagName
with a switch over instanceof self.)
tagName is totally non-virtual in Gecko. It's just a data read out of
the nodeinfo.
It is virtual dispatch, but it'd be only for the methods that *need* to
be virtual.
Yep, I get it now. ;)
I see no obstacles to doing this.
Excellent.
We're treating it as such.
Great. :)
-Boris
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
