My initial reaction would be that String comparison
would be more expensive than int comparison.
I have written a very simple test case where I compare
1 million integers. On my hardware it repeatedly
compares within 15-16 msecs.
Then I compared 1 million strings of 1 char, 2 chars,
3 chars etc. At the beginning it compared them all at
the same time as in int comparisons. I kept the
strings grow in length while keeping the two compared
strings to be the same. When I reach 60 chars the
comparison time started going up to 100 msecs. When I
reach 120 chars it went up to 200 msecs. So it goes
up as string is longer if the two strings are equal.
If they are not equal and the unequality is at the
beginning of the string it compares fast. I would
think Java guys are comparing it char by char.
Got me curious and looked at the code
public boolean equals(Object anObject) {
if (this == anObject) {
return true;
}
if (anObject instanceof String) {
String anotherString = (String)anObject;
int n = count;
if (n == anotherString.count) {
char v1[] = value;
char v2[] = anotherString.value;
int i = offset;
int j = anotherString.offset;
while (n-- != 0) {
if (v1[i++] != v2[j++])
return false;
}
return true;
}
}
return false;
}
BTW, this is IBM JVM implementation. I checked the Sun
JDK 1.4 implementation, too. they are exactly the
same.
So the result would be: The longer the String the more
time consuming it is if the strings are equal.
-Dogan
--- [EMAIL PROTECTED] wrote:
> In a message dated 11/6/2004 3:48:49 PM Eastern
> Standard Time,
> [EMAIL PROTECTED] writes:
> In the Java code I am looking at these days (JMX for
> example) I am
> seeing many places where branches are made based
> upon String equality.
> For example:
>
> void doSomething(String s){
> if (s.equals("some thing"))
> doA();
> else if (s.equals("another thing"))
> doB();
> else
> punt();
> }
>
> Compare that with:
>
> void doSomething(int i){
> if (i == 0)
> doA();
> else if (i == 1)
> doB();
> else
> punt();
> }
>
> I would guess that the int equality can be
> calculated much more rapidly
> than the String equality. String equality might be
> so slow in
> comparison that developers should be wary of this
> practice in code where
> speed matters.
>
> I am aware that sometimes there are big advantages
> to using Strings as
> branch-deciding parameters. I often favor this
> practice, but mostly in
> code that runs infrequently.
>
> But I wonder if anybody knows better. I'm just
> guessing. Has anybody
> seen evidence that String equality can become a time
> hog?
>
> Rich Hammer
> one would think, but it might depend on how the
> underlying code is written.
> When a string object is created--if I were writing
> the object--it'd do some
> kind of check sum with xor or something like that to
> offer some kind of numeric
> identity for the string which would make string
> compare as fast as int compare
> because it would be an int compare.
>
> I do a ton of string compares in my code and they
> seem to go very quickly.
> Might be fun to write a benchmark to compare the
> time it takes to compare a
> hundred million pregenerated random integers as
> opposed to a hundred million
> compares of pregenerated strings of one character,
> two characters, three
> characters, and so on. If the java guys did what I
> would have done, the compares might
> differ a bit between ints and strings, but shouldn't
> vary according to the
> length of the strings. If the compare gets slower
> according to the length of the
> string, bad on java guys.
>
> is it more fun figuring it out by testing it or by
> going into the java code
> and reading how they actually did it? We could do a
> spinal tap before and after
> each and measure the relative amounts of serotonin
> ...
> > _______________________________________________
> Juglist mailing list
> [EMAIL PROTECTED]
>
http://trijug.org/mailman/listinfo/juglist_trijug.org
>
__________________________________
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com
_______________________________________________
Juglist mailing list
[EMAIL PROTECTED]
http://trijug.org/mailman/listinfo/juglist_trijug.org
