My intent was only to respond to the performance analysis, specifically
the implication that the only performance cost is in building the new
hidden class. That is not the case; everything that touches those
objects is affected as well.
Whether or not it's still the right way to accomplish what you're after,
I wasn't venturing an opinion. I could probably come up with a benchmark
showing that your WeakMap approach can be faster -- eg by only accessing
the property once, but feeding the old and new versions of the object
into code that executes many many many times (doing something that never
looks at that property, but is now slightly slower because it isn't
monomorphic). But I suspect that for practical usage, redefining the
property *is* faster than a WeakMap.
If I were to look beyond for other solutions for your problem, then I'm
just speculating. Can decorators populate multiple properties once the
expensive work is done?
I really want to tell the VM what's going on. I guess if it knew that
accessing a getter property would convert it into a value property, and
that it was doing something that would access the getter, then it could
know to use the outgoing shape instead of the incoming shape. If only it
knew that the getter was pure... but that way lies madness.
Given that most code that would slow down would also trigger the lazy
defineProperty(), it's really not going to be that much of an issue. Any
access after the first will see a single shape.
meh. Just take the perf hit, with awareness that you may be triggering
slight slowdowns in all users of that object. Or you might not. I doubt
it'll be that big, since you'll probably just end up with an inline
cache for both shapes and there won't be all that much to optimize based
on knowing a single shape.
Oh, and I think I was wrong about property enumeration order. The
properties already existed, so defineProperty shouldn't modify the order
IIUC. (I am awful with language semantics.)
On 9/11/17 2:48 PM, Andrea Giammarchi wrote:
Steve it's not solved in any other way. Even if you use a WeakMap with
an object, you gonna lazy attach properties to that object.
I honestly would like to see alternatives, if any, 'cause so far there
is a benchmark and it proves already lazy property assignment is
around 4x faster.
So, it's easy to say "it's not the best approach" but apparently hard
to prove that's the case?
Looking forward to see better alternatives.
On Mon, Sep 11, 2017 at 8:15 PM, Steve Fink <[email protected]
<mailto:[email protected]>> wrote:
On 9/11/17 5:36 AM, Matthew Robb wrote:
> I think it's irrelevant if internally VMs are not too happy. VMs
are there to solve our problems, not vice-versa ;-)
This ^ is very important for everyone to get on board with.
Regardless the cost should be negligible as the shape is only
changing at the point of delayed init. This will cause, for
example V8, to deop the object and have to build a new hidden
class but only the one time. I guess it would potentially be
interesting to support an own property that when undefined would
delegate up the proto chain.
(I don't know, but) I would expect it to be worse than this. The
shape is changing at the point of delayed init, which means that
if an engine is associating the possible set of shapes with the
constructor (or some other form of allocation site + mandatory
initialization), then that site will produce multiple shapes. All
code using such objects, if they ever see both shapes, will have
to handle them both. Even worse, if you have several of these
delayed init properties and you end up lazily initializing them in
different orders (which seems relatively easy to do), then the
internal slot offsets will vary.
You don't need to bend over backwards to make things easy for the
VMs, but you don't want to be mean to them either. :-)
Not to mention that the observable property iteration order will vary.
On Mon, Sep 11, 2017 at 7:09 AM, Andrea Giammarchi
<[email protected] <mailto:[email protected]>>
wrote:
Hi Peter.
Unless you have a faster way to do lazy property assignment,
I think it's irrelevant if internally VMs are not too happy.
VMs are there to solve our problems, not vice-versa ;-)
Regards
On Mon, Sep 11, 2017 at 11:54 AM, peter miller
<[email protected] <mailto:[email protected]>>
wrote:
Hi Andrea,
```
class CaseLazy {
get bar() {
var value = Math.random();
Object.defineProperty(this, 'bar', {value});
return value;
}
}
```
Doesn't this count as redefining the shape of the object?
Or are the compilers fine with it?
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
<https://mail.mozilla.org/listinfo/es-discuss>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
