WeakMap.prototype.clear performance

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Jan 22 15:36:51 PST 2013

On Jan 22, 2013, at 2:35 PM, David Bruant wrote:

> So, to find out if a weakmap is dead, it has to come from another source than the mark-and-sweep algorithm (since it losts its precision)...
> Given the additional prohibitive cost weakmaps seem to have on the GC, maybe things that would otherwise be considered too costly could make sense to be applied specifically to WeakMaps. For instance, would the cost of reference-counting only weakmaps be worth the benefit from knowing early that the weakmap is dead? (I have no idea how much each costs, so it's hard for me to compare the costs)
> For WeakMapWithClear, reference counting would declare the weakmap dead as soon as the new weakmap is assigned to the private property so that's good. It wouldn't work if some weakmaps are part of a cycle of course... but maybe that it's such an edge case that it's acceptable to ask users doing that to break their weakmaps cycle manually if they don't want the GC not to be too mad at them.

You know, as much as Jason and I enjoy talking about garbage collectors, this probably isn't the place to revisit the last 40 years of a highly developed area of specialized CS technology.  

We can understand the value of providing a clear method without talking about GC at all.  Map and WeakMap are examples of object abstractions that encapsulate a probably complex implementation level data structure.  As ES programmers we aren't allowed to know very much about the specifics of those data structures other than that the spec. says they must provide average access times that are sublinear with respect to the number of entries in the collection.  The implementation is probably some sort of hash table, but it could be based upon b-trees or some other appropriate data structure.  An implementation might even dynamically change data structures and algorithms as elements are added or removed.

Regardless, as ES programmers that is all forbidden knowledge.  All we  can know and express are things that are exposed through the abstraction's API. An operation like clear, even those it might be possible to achieve the same abstract end result using other operators like delete, allows us to express an intent that tunnels through the abstraction boundary.  For a large number of elements, it is quiet likely that the underlying data structure can be cleared or reset to no entries far more efficiently than  performing an sequence of isolated deletes for the total number of elements.  But if the clear method does it exist we can't express that intent and hence the optimization is impossible.


More information about the es-discuss mailing list