Do we really need the [[HasOwnProperty]] internal method and hasOwn trap
bruant.d at gmail.com
Mon Nov 19 04:04:19 PST 2012
Le 19/11/2012 12:37, Brendan Eich a écrit :
> David Bruant wrote:
>> So my position is let's not bake performance bottlenecks in the
>> language (which we tend to do naturally anyway) and for things that
>> can be optimized, let's say that the implementations will pay the
>> cost of the static/runtime analysis if it's really felt by them like
>> a worthwhile idea.
> No, sorry. Allocations will always cost. It's unphysical to argue
> otherwise. I've been burned too many times by this, even if it's a
> small constant overhead. Those add up, as David Bacon used to point
> out to good effect.
I've made a point where I suggested that with type inference (which cost
has been already paid), the extra allocation could be avoided. My point
is that it would be up to implementors to decide whether using this type
information is worthwhile against the extra allocation. This extra
allocation burns only if it occurs.
I wish to point out a little thought on the topic of memory management.
As far as I know, all GC algorithms I'm aware of are runtime algorithms,
meaning that the primitives of these algorithms are objects and
references between objects. I have never heard of memory management
system that would take advantage of source code informations to not
allocate memory if it's proven to be unused after allocation (or
allocate less if it's proven only part will be used).
Is it a stupid idea? Too much effort? The conjonctions of 2 research
areas where people usually don't talk to one another?
More information about the es-discuss