At a cursory glance, it may not even be slower in an actual browser. I bet
if we profiled it, we wouldn't see that much of a difference, because the
number of statements that have to be execute aren't all that different. And
I bet bit-math vs. regular arithmetic aren't really all that different,
http://gwt-code-reviews.appspot.com/34811/diff/1/3
File user/super/com/google/gwt/emul/java/lang/String.java (right):
http://gwt-code-reviews.appspot.com/34811/diff/1/3#newcode133
Line 133: hashCode |= 0;
On 2009/05/15 15:10:36, robsonbraga wrote:
I don't think you need to convert to 32 bits
LGTM except the simple changes for the test code. Once everyone has
weighed in and the patch is ready to go in, I volunteer to commit it on
your behalf.
Thanks for the patch!
http://gwt-code-reviews.appspot.com/34811/diff/1/3
File user/super/com/google/gwt/emul/java/lang/String.java (right):
It's worth mentioning that, while this algorithm is surely a lot slower than
before, it won't slow down HashMap, which already has a fast-path for string
keys that does not actually use hashCode().
On Thu, May 14, 2009 at 8:33 PM, amitman...@google.com wrote:
LGTM except the simple changes for
