Caveat: I don't actually know much about v8... On Thu, Oct 18, 2012 at 6:39 AM, Jackson Tian <[email protected]> wrote:
> I did a benchmark test for the map function. > > http://jsperf.com/jacksontianmyforpkmap > > the native map method slower than for loop 6x. > > And view the v8 source code, > http://code.google.com/p/v8/source/browse/trunk/src/array.js#1235 > > var result = new $Array(); > var accumulator = new InternalArray(length); > if (%DebugCallbackSupportsStepping(f)) { > for (var i = 0; i < length; i++) { > if (i in array) { > var element = array[i]; > // Prepare break slots for debugger step in. > %DebugPrepareStepInIfStepping(f); > accumulator[i] = %_CallFunction(receiver, element, i, array, f); > } > } > } else { > // This is a duplicate of the previous loop sans debug stepping. > for (var i = 0; i < length; i++) { > if (i in array) { > var element = array[i]; > accumulator[i] = %_CallFunction(receiver, element, i, array, f); > } > } > // End of duplicate. > } > %MoveArrayContents(accumulator, result); > return result; > > There are two strange places: > 1. if (i in array) { > I would imagine that this is the implementation of this step of the ECMAScript[1] definition of Array.prototype.map: a. Let Pk be ToString(k). b. Let kPresent be the result of calling the [[HasProperty]] internal method of O with argument Pk. c. If kPresent is true, then ... Dealing with with "holes" in the array in this manner for map/forEach/etc may not be ideal, but it can't be changed now for these existing methods. (It does seem like there could be some optimization here if the array is known to be dense.) [1] http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf 2. %MoveArrayContents(accumulator, result); > > Could some guys tell me the reason? I love the sugar, but the performance > hurt me. > > -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
