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

Eugene Lazutkin eugene at lazutkin.com
Tue Mar 15 12:18:53 EDT 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yes, it was the totally unfair comparison of bananas with watermelons.
And I argue that our fast bananas are better than standard watermelons.
The driving force should be a use case. I bet bananas to watermelons,
that >99% of all use cases would not involve sparse arrays => standard
array extras do work I don't need.

If it was up to me, I would provide two implementations:

1) Fast for dense arrays, which I will use everywhere.
2) Fair for sparse arrays, which I would not us at all --- I never had a
use case for it yet.

Cheers,

Eugene

On 03/15/2011 10:46 AM, Bryan Forbes wrote:
> 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:
> 
> dojo.forEach:
> =============
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1/kWkACgkQY214tZwSfCuI5gCghnGqchVZ8BW6qCNgruLvuZRn
zNIAoMuG1q2O6qp+xbZWy2WIvz3D75Ud
=5Cnn
-----END PGP SIGNATURE-----


More information about the dojo-contributors mailing list