On 12/26/2012 01:19 PM, Boris Zbarsky wrote:
jdm mentioned that he's working on DOM bindings again, so I wanted to
write down the things that we've run into as performance or usability
gotchas in Gecko bindings so far.
I don't have thoughts on all these topics, but I'll try to respond to
some. Hopefully others can chime in.
Performance:
1) For interface types, one needs a very fast way to unwrap them to
some sort of object you can call methods on. In Gecko this is done by
ensuring that all the classes representing DOM prototypes for a
particular object have the same pointer so you can reinterpret_cast
between them (for example, the EventTarget*, Node*, Element*,
HTMLElement*, and HTMLDivElement* for an HTML <div> all have the same
value). Then that one pointer can be stored in the JS object, and all
you have to check at runtime is that the the cast is safe.
What do we plan to do for the memory layout of DOM objects, and how do
we plan to make it work with binding code?
This sounds like you are asking for DOM types that use inheritance. We
have some proposals for adding simple single inheritance to the language
(motivated primarily by the needs of servo's DOM) that I'm not that
familiar with. I assume that it's important to also have static dispatch
on the method calls, which seems to me the harder part, but pcwalton
says we will have a solution.
2) For sequence in params for WebGL, you really want to
stack-allocate the array for short arrays. Passing very short
sequences for uniform*fv is common, and heap-allocation is expensive.
From Rust's perspective this shouldn't be a problem since we can make
vectors on the stack.
3) Strings are a major pain point. You want to be able to share
strings between SpiderMonkey and your DOM stuff for return values.
You also want some sort of JSString* cache, though this is not
fundamental to the design and can be tacked on easily, I think. I
know we have plans to sorta using JSString* internally kinda; the
might be nice.
I've been worrying a bit about string representations and interning. Our
current CSS implementation uses its own string format and interner, with
all the conversions that implies. It was not designed for multithreading
and now has a global lock. This will affect performance everywhere. My
understanding is that JSString is not threadsafe either.
Can JSString be modified to work correctly and fast in a multithreaded
setting? I know Niko has hit this problem with RiverTrail as well.
4) It helps a huge amount to be able to inline the implementation
into the binding or at least make it a non-virtual function call.
Virtual function calls are terrible not just because of the
indirection but also because of fairly common cache misses on the
vtable lookup.
Patrick and I have discussed modifications to the Rust FFI to allow
foreign code to directly call Rust functions, avoiding both the stack
switching and indirect calls. I agree we need this.
Usability:
1) Ownership model (though at this point CC is getting more usable).
In Gecko this is exacerbated by there being different models on main
thread and in workers; let's please avoid that.
2) You want the same representation for arguments of both callback
interfaces and natively implemented interfaces. Otherwise you get
annoying impedance mismatches. We're working around those in Gecko
with evil conversion operators, since you can do that in C++, but it's
slightly suboptimal. The fact that we don't have to worry about ref
vs pointer vs NonNull<T> in Rust will help here. But that doesn't
necessarily help with the fallible/infallible array mess.
3) The combination of the two, where you can't necessarily use the
same type for Node in both Node and sequence<Node> arguments because
for the former you want to be fast while for the latter you have to
keep the Nodes in the sequence alive.
4) Dictionary return arguments are a bit of a pain point. See
https://bugzilla.mozilla.org/show_bug.cgi?id=817194
I am not familiar with nor do I understand these issues.
_______________________________________________
dev-servo mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-servo
