Lazy evaluation

Naveen Chawla naveen.chwl at gmail.com
Tue Sep 12 07:56:21 UTC 2017


https://www.npmjs.com/package/decorator-memoize
https://www.npmjs.com/package/memoized-decorator
https://www.npmjs.com/package/memoize-decorator

Relevant?

On Tue, 12 Sep 2017 at 03:18 Andrea Giammarchi <andrea.giammarchi at gmail.com>
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 <sphink at gmail.com> 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 <
>> andrea.giammarchi at gmail.com> 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 <fuchsia.groan at virgin.net
>>> > 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
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170912/3a332479/attachment.html>


More information about the es-discuss mailing list