Use strict when possible. Don't even try to cache the hashcode for strings.

Use strict when possible. Don't even try to cache the hashcode for strings.

Committed: https://code.google.com/p/dart/source/detail?r=1745

[floitsch, 2011-11-09 21:11:26]

'use strict'; whenever possible.
Compliant browsers don't need to box the primitive types anymore which gives a
huge speed-improvement on Chrome. (for some values).
Also: it is not possible to box the hashcode of a string on the primitive
string. And caching it on the temporary box doesn't make sense either. That
means that the hashcode is currently recomputed *every* time. (This is bad).

[floitsch, 2011-11-18 14:17:41]

ping

[jgw, 2011-11-22 14:25:33]

On 2011/11/18 14:17:41, floitsch wrote:
> ping

Whoops, sorry I missed this. I don't see any way this could make things worse,
so if it speeds things up, LGTM!

[sra1, 2011-11-22 18:13:39]

http://codereview.chromium.org/8511023/diff/1/compiler/lib/implementation/str...
File compiler/lib/implementation/string.js (right):

http://codereview.chromium.org/8511023/diff/1/compiler/lib/implementation/str...
compiler/lib/implementation/string.js:96: "use strict";
What is the benefit of "use strict" in this and the other functions?  Does it
make a measurable performance improvement?

http://codereview.chromium.org/8511023/diff/1/compiler/lib/implementation/str...
compiler/lib/implementation/string.js:101: hash += hash << 10;
The result of += can be outside the 32-bit range of << and ^= leading to boxing.
 I think this loop needs to be carefully rewritten so that the common browsers
all are fast.

I'm wondering where this hash function originated, and if we intend to define
the hash code of a string.

[floitsch, 2011-11-23 09:21:54]

http://codereview.chromium.org/8511023/diff/1/compiler/lib/implementation/str...
File compiler/lib/implementation/string.js (right):

http://codereview.chromium.org/8511023/diff/1/compiler/lib/implementation/str...
compiler/lib/implementation/string.js:96: "use strict";
On 2011/11/22 18:13:39, sra1 wrote:
> What is the benefit of "use strict" in this and the other functions?  Does it
> make a measurable performance improvement?
"use strict" doesn't wrap the object. So (3).hashCode() will not go through the
boxing.
Iirc we saw a *5 improvement on the raytracer (that some external user submitted
to the mailing list a long time ago).

http://codereview.chromium.org/8511023/diff/1/compiler/lib/implementation/str...
compiler/lib/implementation/string.js:101: hash += hash << 10;
On 2011/11/22 18:13:39, sra1 wrote:
> The result of += can be outside the 32-bit range of << and ^= leading to
boxing.
>  I think this loop needs to be carefully rewritten so that the common browsers
> all are fast.
> 
> I'm wondering where this hash function originated, and if we intend to define
> the hash code of a string.

Given that we can't store the hash we should rethink our hashing strategy
anyways.
Maybe open a bug?