Monreal: Aivot-on: using a for loop

Headings: Appears a fix won’t make it into Crankshaft but TurboFan will finally opt it

Baffa: Https://codereview.chromium.org/330303002/

Kalinoski: Yeah ES6 gives you a lot of ways to deal with arguments

Bielec: Goyette: apart from not breaking legacy browsers

Castelli: Hopefully Array.from will optimize as well

Kalinoski: Including the splat operator

Mis: Vafiadis: I think the engine knows how to optimize arguments.length and arguments0, replacing them with variables; but if it can’t do that, e.g. you p*** arguments to a function, it’s forced to actually create the object

Vafiadis: Goyette: TIL the arguments object has a Symbol.iterator property ;-

Madeau: STRML: Array and from could be overridden :-

Vafiadis: But yeah, this may depend also on how array.from and symbol.iterator is polyfilled

Vafiadis: I also wonder if argumentsSymbol.iterator is totally free of the issue

Takata: Yeah, Array.from could be overridden but that’s madness

Kalinoski: Yeah I wouldn’t bother to support environments where built-in objects were mutated

Nodal: Vafiadis: I think it potentially could be, but they may not have gotten around to it

Gerfin: I believe spread params will probably be optimized before Array.fromarguments or .slice.callarguments

Neglia: Destructuring/spread should also be optimizable, I believe

Vafiadis: Well, the question of whether using Array.from is optimized is a slightly different from one whether it will deoptimize the function, no?

Mariner: Whether it can be optimized

Kalinoski: Creating the arguments object in the first place has a cost

Mudrick: If it’s mutable, it can’t

Nolf: Array.from currently isn’t optimized

Lowther: Still about 25x slower than a for loop

Docherty: About 15% faster than .slice.callarguments

Spoon: Http://jsperf.com/copy-fn-arguments-test/18

Vafiadis: I always find that interesting, since you’d think the native could would simply be a matter of changing it into a for/while loop

Benac: Well, in V8 leaking the arguments object to a function causes deopt

Mesch: So whether that function is Array#slice or Array.from, the result is the same

Vafiadis: STRML: oh, you mean Array.from is 24x slow than a for loop with arguments object, not Array.from in general?

Stimits: Petka uses an INLINE_SLICE macro in bluebird since you can’t p*** it to a function

Trupia: Vafiadis: yes, it’s faster than slice, and probably the same as anything else when not using arguments

Schultes: But still far slower than a for loop

Vafiadis: That makes sense then, yeah

Kalinoski: Parsing the arguments is pretty darn fast no matter how you do it. compared to the real work you’re probably doing

Hernande: Depends on how hot the function is, but yes, I agree

Lausen: But that’s one of the reasons why bluebird is an order of magnitude faster than the other promises implementations

Vafiadis: Oh neat- babel used to use the slice method I believe, but it now uses a for loop instead

Vafiadis: For the spread operator

Gort: Yep. Babel is getting some great contributions now

Baldree: Especially now that it has effectively replaced react-tools

Julien: Too bad it’s so slow to process. but it does much more.

Reineck: We went to a restaurant called baabel today

Reineck: Thought about posting a joke about it on twitter with a photo. “pizzas for ES6 programmers”

Reineck: Extra A due to finnish variation of word babel

Yunt: Zomg somefrom from finland

Kalinoski: I would even give it an A+ ;