[dojo-contributors] Dojo 1.7 Goals: has() and granular dependency lists

Bryan Forbes bryan at reigndropsfall.net
Tue Mar 15 11:46:01 EDT 2011

Hash: SHA1

Comments inline.

On 3/15/11 10:09 AM, Eugene Lazutkin wrote:
> If memory serves me correctly, this decision (use our implementation in
> all browsers) was done because of two factors: in almost all browsers
> native implementations were *slower* than trivial JavaScript once, and
> because of space considerations --- why ship two implemntations + a
> switch between them, if there are no other benefits?
> Just ran a test in Chrome 11 on Linux --- native versions 2-3 times
> slower on this benchmark: http://www.perfjs.com/#638003
> I tried it on FF3.6 --- forEach is twice slower, yet reduce* is almost
> the same.

To be fair, the native implementations will do more checks than our
forEach does because they follow the ES5 spec of not invoking the
callback for "holes" in a sparse array. Compare:

for(var i=0, l=arr.length; i<l; ++i){
    callback.call(scope, arr[i], i, arr);

ES5 forEach:
for(var i=0, l=arr.length; i<l; ++i){
    if(i in arr){
        callback.call(scope, arr[i], i, arr);

This means that the overhead of implementing an ES5 compliant forEach is
at least O(n) greater than implementing a non-ES5 compliant forEach. All
that to say: it's an unfair comparison. A better comparison would be
comparing all three (native, non-ES5, and ES5) so we can see what the
check does in non-native code: http://jsperf.com/foreach-native-vs-js

In Chrome 10, the order is (from most performant to least) non-ES5,
native, ES5. In Firefox 3.6, the order is native, non-ES5, ES5. To me,
if native comes in first or second (behind the non-ES5 implementation),
we should eventually go with native and be ES5 compliant (I'm also
talking 2.0, not 1.x).

- -Bryan

> It appears that the current generation of browsers do not give us clear
> incentive to switch, other than for possible build reduction purposes.
> Cheers,
> Eugene Lazutkin
> http://lazutkin.com/
> On 03/15/2011 08:32 AM, Peter Higgins wrote:
>> All the array utilities do this in the webkit mobile build (use natives,
>> weird weird pragma at the bottom), but we were never serving native
>> iterators as our own even in browsers that support it.
>> On 3/15/11 9:13 AM, Kris Zyp wrote:
>>> On 3/14/2011 10:24 PM, Bill Keese wrote:
>>>> Doesn't your patch break backwards-compatibility?     Note the
>>>> comment in all the methods in the current code:
>>>> //This method corresponds to the JavaScript 1.6 Array.indexOf method,
>>>> with one difference: when
>>>> //run over sparse arrays, the Dojo function invokes the callback for
>>>> every index whereas JavaScript
>>>> //1.6's indexOf skips the holes in the sparse array.
>>> I didn't write any new code, I just switched from the old build pragma
>>> to has() branching. If it is not backwards-compatible, it hasn't been
>>> backwards-compatible for sometime... So it is backwards-compatible
>>> with the old backwards-incompatibility ;).
>>> Kris
>>> _______________________________________________
>>> dojo-contributors mailing list
>>> dojo-contributors at mail.dojotoolkit.org
>>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>> _______________________________________________
>> dojo-contributors mailing list
>> dojo-contributors at mail.dojotoolkit.org
>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the dojo-contributors mailing list