This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Originally posted by Jon Dornback: I am reading in input from a socket, and need to compare it to a string value. which is faster:
thanks in advance, Jon [ February 10, 2003: Message edited by: Jon Dornback ]
Hi Jon Dornback You could test it by doing a simple test like the following.
Here is the output I got on it. Time for method1 : method 2 0 : 20 0 : 20 0 : 0 10 : 0 0 : 0 0 : 0 0 : 10 0 : 0 0 : 0 10 : 0 0 : 0 Now here I stared noticing a few things. A) if the byte's are not the same then the Arrays.equals() method can be faster by first checking if the lenght of the two arrays are the same, if not they cannot contain the same data. B) If the byte's are large arrays and the first byte in each array differ the Arrays.equals() can stop checking them right there, but if they are simmilar except for the last byte in the array then it could take a bit more time to compare them. Here is the code for String.equals()
Note 1 : This seems to speed thing up if the object being tested is not a String, but we know it is a String so this in not going to affect us. Note 2 : This seems to be how I think they did it for in the Arrays.equals also, they first check the lenght of the String. Note 3 : same as point B above... larger Strings will make more of a diffrence. Thus I revised the code for the TestSpeed class to the following.
and Here is the outPut Time for method1 : method 2 10 : 40 40 : 30 10 : 10 20 : 0 10 : 10 10 : 10 20 : 10 10 : 10 10 : 10 10 : 20 10 : 10 Here is the code for the Arrays.equals();
So it seems that they are more or less the same code. The funny thinging is that I'm thinking wouldn't it have been more OO if String.equals looked like this.
Any Body can be paid to write good code, but brilliant code can only come from passion
Joined: Apr 24, 2002
Thanks for the help. From the averages of your test runs, it looks like the comparisons are close enough in speed that it won't matter much which one is used. thanks Jon
Joined: Jul 03, 2001
Originally posted by hennie louw: So it seems that they are more or less the same code. The funny thinging is that I'm thinking wouldn't it have been more OO if String.equals looked like this.
I'd just like to point out some thing that I've noticed here. I still think that the way as above will be more OO but it will be slower. If one uses the Arrays.equals(char Char) instead of duplicating the code you will be using one more clock cycle on the processor to check if the string is equal to one another. by the call to Arrays.equals(char , char) Now one clock cycle doesn't sound like to much, but what if you were to call String.equals in a for loop of about 1000000 time or so? you would have to wait an extra 1000000 clock cycles if it did call Arrays.equals instead of just duplicating the code at an very small memory cost.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com
subject: fastest equality check: 2 strings, or 2 byte?