Questioning WeakMap.prototype.clear

Jason Orendorff jason.orendorff at gmail.com
Tue Jan 22 06:59:08 PST 2013


On Tue, Jan 22, 2013 at 5:56 AM, David Bruant <bruant.d at gmail.com> wrote:

> However, Mark showed an elegant way to implement .clear on top of
> clear-less weakmaps and the class syntax [4][5] (reproducing here the final
> version for clarity)
>

Sure—and roughly the same code can be used to *remove* an unwanted .clear()
method:

    class WeakMapWithoutClear {
        // (this is just all your code except the clear method)
        private let wrapped;
        constructor() {
            wrapped = new WeakMap();
        }
        get(key) => wrapped.get(key),
        set(key, val) => wrapped.set(key, value),
        has(key) => wrapped.has(key),
        delete(key) => wrapped.delete(key),
    }

So the workaround is about equally elegant either way. (And just for the
sake of kidding you a little: the Without hack is more general and seems
like it ought to be pretty familiar to an o-c hacker!)

Then there are two issues to address. We already have lots of things named
"1" and "2" in this thread, so:

A) Are there more WeakMap applications that will want .clear() or
applications that will want .clear() not to exist? Offhand I would bet on
the former, by a landslide, but if you think otherwise, or if there's some
other reason to privilege .clear() not existing, let's talk about that.

B) What you said:

Now, the only thing that can differentiate both the native against this
> version is performance I think. Allen seems to argue that a native .clear
> would have better perf characteristics (related to GC). I still fail to see
> why the difference would be significant (but I need to re-read his recent
> posts about that).
>

Definitely re-read them. They made sense to me. If you have questions about
the implementation of GC through WeakMaps, I'll happily share what I know.

In all likelihood, .clear is a method that is used sporadically. At least,
> one needs to fill up the weakmap a bit before calling it, so I don't think
> a marginal perf difference would matter.
>

The perf difference Allen is talking about is not marginal.

As an implementor, what is your feeling about performance characteristics
> of both the native and the class-based version?
>

Heh! I'm the worst person to ask about this. I'm not comfortable with the
worst-case GC performance of WeakMaps to begin with. My main coping
mechanism is not thinking about it!

In our current implementation, creating a new WeakMap and dropping the old
one is very nearly equivalent in performance to clear(). However that's
because we don't have a generational GC today. Dead WeakMaps are promptly
collected. In another year, that will change. If we end up with more than
two generations, I think it'll lead to exactly the problems Allen foresees.
Maybe even if we just have two generations. (To some extent, long-lived
ordinary Maps and Arrays also do this in a generational GC; but WeakMaps
have much, much worse worst-case GC performance.)

Having said all that, I bet we could hack around the worst-case GC
performance. It'll be a pain, but GC is like that sometimes. This decision
should hinge on what provides the best API for developers. I think we
mainly disagree on what developers want, which is a great thing to talk
about. Let's talk about that.

-j
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130122/5fa653a1/attachment.html>


More information about the es-discuss mailing list