I'd say it's a known issue that generic Array built-ins are slower than
handwritten less generic versions.
Array you are mapping over is extremely small so all overheads of a generic
implementation are highlighted. For example %MoveArrayContents amounts to
20% of the overheads, while in reallity it just swaps around some pointers.
If you are into function programming (which I know you are :-)) you can
have your own, less generic version:
Array.prototype.fastMap = function (cb) {
"use strict";
var result = new Array(this.length);
for (var i = 0; i < this.length; i++) result[i] = cb(this[i]);
return result;
};
However I'd also argue that it is not impossible to optimize overhead away
in majority of common cases using combination of inlining, constant
propagation and some other optimizations. e.g. hasOwnProperty check can be
fused with actual load or completely eliminated (depending if backing store
is holey or not). It just requires some plumbing. Even V8's approach to
function inlining does not really work with high order code. (instead of
checking closure identity, it's "literal" identity should be checked:
https://code.google.com/p/v8/issues/detail?id=2206).
An alternative approach could provide specializations of map for various
backing storage types. But again, there is no plumbing in V8 to enable that.
Vyacheslav Egorov
On Mon, Feb 4, 2013 at 4:17 PM, Andreas Rossberg <rossb...@google.com>wrote:
> Moreover, 'map' has to make a hasOwnProperty check in every iteration.
>
> /Andreas
>
> On 4 February 2013 16:14, Sven Panne <svenpa...@chromium.org> wrote:
> > On Mon, Feb 4, 2013 at 3:58 PM, Andrii Melnykov <andy.melni...@gmail.com
> >
> > wrote:
> >>
> >> http://hpaste.org/81784 contains a benchmark - slow_test() is twice as
> >> slow as fast_test() [...]
> >
> >
> > The way Array.prototype.map is specified (see section 15.4.4.19 in the
> ECMA
> > spec) makes it very hard to implement efficiently. One has to create a
> new
> > array for the result and has to be prepared for the case when the
> callback
> > function modifies the array. Furthermore, we don't do any deforestation,
> > which is "a bit" hard in JavaScript. Therefore, fast_test() basically
> does
> > something different than slow_test(): It is optimized knowing the fact
> that
> > the callback function does not modify the underlying array + it does the
> > deforestation by hand, avoiding the need for an intermediate array.
> >
> > In a nutshell: It shouldn't be a surprise that fast_test() is, well,
> faster
> > than slow_test()...
> >
> > --
> > --
> > v8-users mailing list
> > v8-users@googlegroups.com
> > 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 v8-users+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> 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 v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
--
v8-users mailing list
v8-users@googlegroups.com
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 v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
