Sounds reasonable, but wouldn't it make sense to make this pattern matching based on internal references (plus refcount) instead of variable-name matching? That would solve the issue probably.
Above that, I agree that the limiting factors are based on function calls if it's implemented in a naive way. However, I think ES6 gives a huge opportunity introducing a lot of high-level semantic information, which can be used to infer what the user wants and execute it much faster. So even if the user writes down a function call, it can be a simple loop inside of v8. I thought it's already done this way, when I heard ES6 became much faster recently. On Friday, March 4, 2016 at 11:34:51 AM UTC+1, Jakob Kummerow wrote: > > On Thu, Mar 3, 2016 at 7:48 PM, 'Robert Eisele' via v8-users < > [email protected] <javascript:>> wrote: > >> Hi, >> >> I wonder if v8 is able to optimize the pattern >> >> A = A.map(x => ~x) >> >> In this case v8 can work on the array instead of creating a new object >> and replacing it with the original array. >> > > Counter-example: > var A = B; > A = A.map(...); > // B must not have been modified > > You can make these as complicated as you want: > var B = [1, 2, 3]; > (function(A) { > A = A.map(...); // How can this .map() call know that B exists? > })(B); > > In general, it's pretty much impossible to tell whether there are any > additional references to an object somewhere; the only exception is when > the object has just been allocated in the current function. > > Also, on the scale of machine instructions, the overhead of a function > call is pretty large, which affects many of the Array builtins like .map() > and .forEach(). In many real usage scenarios, that might not matter, > because the arrays in question are small enough and/or the callbacks > themselves expensive enough that call overhead doesn't make much of a > difference. But when you micro-benchmark simple cases like "A.map(x => ~x)" > vs. "for (var i = 0; i < A.length; i++) { A[i] = ~A[i]; }" for a couple > million elements, you'll see a pretty big difference, and the majority of > that will be caused by the function calls. > > >> Is such a behavior already implemented? >> > > No, because it's complicated, and the benefit is somewhat unclear. We > might be able to optimize some patterns in the (distant) future. > > >> Thanks! >> >> -- >> -- >> v8-users mailing list >> [email protected] <javascript:> >> http://groups.google.com/group/v8-users >> --- >> You received this message because you are subscribed to the Google Groups >> "v8-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
