On Nov 30, 2011, at 8:15 AM, David Bruant wrote:
>>
> Avoiding an extra allocation is the only worry for this last point. Very much
> like Tom worried about mirror allocation at
> https://mail.mozilla.org/pipermail/es-discuss/2011-November/018734.html
>
> Digression about memory in JS implementations:
> I've been following the MemShrink effort in Firefox. Data structures have
> been shrinked, fragmentation has been reduced making a better use of memory,
> but I have seen much less work toward reducing the number of allocations.
> This is certainly because the study of when an allocation is required or not
> is usually complicated.
A sign that your garbage collector isn't good enough: People are writing style
guides that tell developers that they should avoid allocating objects.
Objects serve as one of our primary abstraction mechanisms (the other is
functions and function closures have similar allocation issues). Anytime you
you tell programmers not to allocate you take away their ability use
abstraction to deal with complexity.
A good GC should (and can) make allocation and reclamation of highly ephemeral
objects so cheap that developers simply shouldn't worry about it. This is not
to say that there are no situations where excessive allocations may cause
performance issues but such situations should be outliers that only need to be
dealt with when they are actually identified as being a bottleneck. To over
simplify: a good bump allocation makes object creation nearly as efficient as
assigning to local variables and a good multi-generation ephemeral collector
has a GC cost that is proportional to the number of retained objects not the
number of allocated objects. Objects that are created and discarded within the
span of a single ephemeral collection cycle should have a very low cost. This
has all been demonstrated in high perf memory managers for Smalltalk and Lisp.
> I don't know what the exact status of implementations is, but what happens in
> current JS engines when the expression '[].forEach.call' is met? Is the
> allocation of an array actually performed? Hopefully not, I would not be
> surprised if it was.
I suspect they don't optimize this although arguably they should. However, if
you buy my argument then it really doesn't make much difference.
Implementations should put the effort into building better GCs.
> ...
> Looking through Promise methods
> (http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#promise_methods),
> I realize that these (besides p.when and p.end) could just be replaced by
> the Reflection API being adapted to work with promises.
Stated slightly differently, a promise can be thought of as a specific kind of
object mirror.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
