January 17, 2009
Comparing strings in Java - benchmark results
I've made benchmark for 2 different .equals() calls VS hashCode() comparing. Here are the variants:
1) constS.equals(variableS)
2) varS.equals(constS)
3) varHash (computed on each iteration) == constHash
4) varHash (computed before) == constHash (this is actually just int comparision!)
Note: my timer resulution seems to be 10ms.
The results on 1024000 iterations (run in interpreter mode) are:
Time: 170 ms.
Time: 180 ms.
Time: 461 ms.
Time: 40 ms.
With HotSpot, 1024000 its.:
Time: 20 ms.
Time: 20 ms.
Time: 60 ms.
Time: 10 ms.
So, it seems that the idea with preparing hashcodes to compare them with searched one later is very good idea. Also, it does not matter which one to compare to which one: var to const or vice versa.
1) constS.equals(variableS)
2) varS.equals(constS)
3) varHash (computed on each iteration) == constHash
4) varHash (computed before) == constHash (this is actually just int comparision!)
Note: my timer resulution seems to be 10ms.
The results on 1024000 iterations (run in interpreter mode) are:
Time: 170 ms.
Time: 180 ms.
Time: 461 ms.
Time: 40 ms.
With HotSpot, 1024000 its.:
Time: 20 ms.
Time: 20 ms.
Time: 60 ms.
Time: 10 ms.
So, it seems that the idea with preparing hashcodes to compare them with searched one later is very good idea. Also, it does not matter which one to compare to which one: var to const or vice versa.
Comments:
<< Home
Emmm...
I think that synthetic tests don't fully reflect the reality but they show us a trend of course :)
I think that synthetic tests don't fully reflect the reality but they show us a trend of course :)
# posted by 
: 6:29 PM, January 17, 2009
: 6:29 PM, January 17, 2009
agree. numbers just for comparision. forget to mension that it's interesting for those who parse xml at j2me devices.
Post a Comment
<< Home
