On Sun, Feb 15, 2015 at 7:43 AM, Benjamin (Inglor) Gruenbaum < [email protected]> wrote:
> This is actually exactly the kind of slow code Katelyn was talking about. > Also, you probably meant `set[Symbol.iterator]()` and `for... of`. > You are correct. I haven't switched to the 'of' syntax yet (need to do that). > > 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 > I did implement my own, yes. > > > 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. > I may have misunderstood; it sounded to me like the two of you were agreeing that JS VMs won't be doing this anytime soon. > > > 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. > Exactly how would developers mutate the return object in the first place? And frankly, I don't see how you can care so little about a major, show-stopping issue such as this. JS performance has gotten to the point where people like me write *CAD software* in it. Usable iterators are important for such things. Frankly, I find this sudden embrace of good coding practices odd in a language that practically sets the floor for how horrendously mutable a dynamic runtime language can get. > > On Sun, Feb 15, 2015 at 3:35 PM, joe <[email protected]> wrote: > > >> >> On Sun, Feb 15, 2015 at 7:16 AM, Benjamin (Inglor) Gruenbaum < >> [email protected]> 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 <[email protected]> wrote: > >> >> >> On Sun, Feb 15, 2015 at 7:16 AM, Benjamin (Inglor) Gruenbaum < >> [email protected]> 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
