This is actually exactly the kind of slow code Katelyn was talking about.
Also, you probably meant `set[Symbol.iterator]()` and `for... of`.
What Katelyn is talking about is optimizing .next in the example code to
not return a new object but to return the same one every time with
different values filled in. In order to optimize that with your transpiler
you'd need to implement your own `Set` and `Map` because like Katelyn
correctly noted `Set` and `Map` do not expose a fast way (in current
implementations) to iterate them at the moment - at least until engines
optimize them.
Katelyn is arguing it would be useful to allow the implementation to return
the same instance and I'm arguing the reason it's slow is because it's
benchmarked against a slow implementation that was not optimized yet but
can easily be - just like Katelyn noted as LuaJIT does.
When I can get more sound abstractions for no additional cost (eventually)
I'd rather not introduce implicit mutable state into the application.
Developers won't be aware of it being mutating and the whole notion of a
mutating-at-a-later-point return value is very error-prone in my opinion.
On Sun, Feb 15, 2015 at 3:35 PM, joe <joe...@gmail.com> wrote:
>
>
> On Sun, Feb 15, 2015 at 7:16 AM, Benjamin (Inglor) Gruenbaum <
> ing...@gmail.com> wrote:
>
>>
>> This is something that can be solved at the VM level. VMs perform much
>> much smarter optimizations than this already. There is no reason to
>> sacrifice code correctness and the principle of least astonishment in order
>> to get acceptable performance. Benchmarking against "proof of concept"
>> implementations is counter-productive in my opinion. The engines are
>> already 'allowed' to use the same object when there is no observable
>> difference. Even if we allow this 'optimization' it will take the engines
>> as much time to implement it so there is no gain from this anyway.
>>
>> ______________________________________________
>>
>
> Is 60,000 lines of source code a good enough "proof of concept for you"?
>
> I don't see what the problem is. My transpiler generators the following
> ES5 code:
>
> //for (var item in set)
>
> var iter = obj.iterator();
> while (1) {
> var ret = obj.next();
>
> if (ret.done) break;
> var item = ret.value;
> ...loop body
> }
>
> It works quite well. You may be right about the VM vendors, however.
> This requirement basically makes JS useless for anything other than minor
> scripting tasks. The VM people may not have any choice but to optimize it.
>
> Joe
>
>
On Sun, Feb 15, 2015 at 3:35 PM, joe <joe...@gmail.com> wrote:
>
>
> On Sun, Feb 15, 2015 at 7:16 AM, Benjamin (Inglor) Gruenbaum <
> ing...@gmail.com> wrote:
>
>>
>> This is something that can be solved at the VM level. VMs perform much
>> much smarter optimizations than this already. There is no reason to
>> sacrifice code correctness and the principle of least astonishment in order
>> to get acceptable performance. Benchmarking against "proof of concept"
>> implementations is counter-productive in my opinion. The engines are
>> already 'allowed' to use the same object when there is no observable
>> difference. Even if we allow this 'optimization' it will take the engines
>> as much time to implement it so there is no gain from this anyway.
>>
>> ______________________________________________
>>
>
> Is 60,000 lines of source code a good enough "proof of concept for you"?
>
> I don't see what the problem is. My transpiler generators the following
> ES5 code:
>
> //for (var item in set)
>
> var iter = obj.iterator();
> while (1) {
> var ret = obj.next();
>
> if (ret.done) break;
> var item = ret.value;
> ...loop body
> }
>
> It works quite well. You may be right about the VM vendors, however.
> This requirement basically makes JS useless for anything other than minor
> scripting tasks. The VM people may not have any choice but to optimize it.
>
> Joe
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
