On Thu, Nov 1, 2012 at 4:10 PM, Maciej Stachowiak <[email protected]> wrote: > On Nov 1, 2012, at 6:36 PM, Adam Barth <[email protected]> wrote: >> We currently use two different approaches for associating JavaScript >> wrappers with DOM objects. For some objects, we store the wrapper >> inline in the object itself by making object inherit from >> ScriptWrappable. For other types of objects, we use a HashMap to >> translate the object into a JavaScript wrapper. >> >> Whether to use ScriptWrappable or a HashMap is a trade-off that >> depends on the workload. For DOM objects that rarely have a >> JavaScript wrapper, using a HashMap is more memory efficient because >> we don't need to store a large number of null pointers in objects that >> do not have wrappers. By contrast, if an object almost always has a >> JavaScript wrapper, using ScriptWrappable is both faster (because we >> avoid the hash table lookup) and uses less memory (because we don't >> need to store both the key and the value in the HashMap---we just need >> to store the value in the object itself). >> >> Today, we use ScriptWrappable for Nodes only, but we would benefit by >> making more use of ScriptWrappable, particularly for DOM objects that >> almost always have JavaScript wrappers. For example, XMLHttpRequest >> objects exist only when created by script, which means that every >> XMLHttpRequest object has a JavaScript wrapper. >> >> My plan is to introduce an interface-level IDL attribute named >> something like [OftenHasJSWrapper] that informs the code generator >> that the object inherits from ScriptWrappable and that we should make >> use of the inline wrapper. We can then deploy this attribute as >> appropriate throughout WebCore to reduce memory usage and improve >> performance. >> >> Please let me know if you have any feedback. > > Sounds like a good idea. Three additional thoughts: > > (1) It would be best to choose the objects to apply this to in some > data-driven way. > (2) If we have an IDL attribute, I think it should be named by the effect it > has, not the possible conceptual-level reason for applying it. > [ScriptWrappable] or [InlineWrapper] or something. Because it's not a > judgment call, it is a statement about the code. > (3) I suspect that we can handle this without adding an IDL attribute at all. > C++ overloaded functions could let the bindings do something different for > objects that inherit ScriptWrappable from ones that do not in a generic way, > without having to explicitly tell the bindings layer about the ways to do it. > Consider the ways unwrap() and toJS() are done. We don't have to say anything > special in the IDL or have any interface-specific knowledge in the bindings, > C++ overloading takes care of it.
That's a good idea. I'll see if we can avoid the IDL attribute. I wonder if we can do the same for the ActiveDOMObject IDL attribute, which similarly announces the presence of a base class. Adam _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
