Le 07/04/2011 19:27, Brendan Eich a écrit : > On Apr 5, 2011, at 2:19 PM, David Bruant wrote: > >> What I'm worried about is the memory cost of such an implementation. >> The current [[HasInstance]] implementation has a constant memory >> cost. Keeping references has a linear memory cost in terms of >> instance number. My favorite real-world memory-intensive use case is >> the one-page Standard HTML >> (http://www.whatwg.org/specs/web-apps/current-work/). Right now, it >> contains 125684 DOM Elements. If trying to implement EventTarget >> [[HasInstance]] internal method, it would require as many entries in >> the WeakMap. > > First, there's no free lunch. Either the DOM objects need internal > fields (vptrs in C++ sense, plus static shared vtbls) or brands or > trademarks, which is per-object overhead. Or we need an entry in a > weakmap for each object, which can be quite efficient (better if the > map were a set, but still). > > Second, although the details do matter, the asymptotic space > complexity is the same, ignoring static or singleton costs which > amortize to epsilon: k*n for constant k and n objects, or O(n). I agree. I'd like to point out that WebIDL/DOMCore solution (EventTarget.prototype in Node.prototype chain) is a third solution for which there may be no further memory cost since the prototype chain has to be here anyway.
The EventTarget example was only here for illustration purposes. People may create several constructors (with an hasInstance+WeakMap inheritance) having several tens of thousands of instances each (implementors may have encounter people creating millions of instances sometimes?). Can ES engines handle that? If they can, then everything is fine. If they cannot, we may question the hasInstance trap. Usual inheritance has a constant memory cost since the prototype chain is shared. Tell me if I'm wrong, but the DOM inheritance has a limited memory footprint due to the fact that several constructors can share the same internal fields and it's in C++. It may be a different story when people will create constructors with one WeakMap each. > The time complexity to test is-a would be O(1), but of course as David > Bacon likes to point out, small constant factors can matter: a field > load and compare beats a hashtable lookup. A C++ virtual call to > QueryInterface or the like is slower than a well-implemented hashtable > lookup. > > Again, big-O does not distinguish even if some benchmarks run on > different implementations could tell. I'll agree that as long as it's fast enough for real life uses, the actual big-O or multiplicative constants are of no interest. For instance, the current inheritance has a O(n) complexity (prototype chain traversing), but in real life, I've never seen a prototype chain with 10 elements. David _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
