This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
In jProbe profiler I see String.valueOf method is being called lot of times and is consuming considerable amount of time. I want to compare string with int. I can convert STring to int or viceversa. Should I use Integer.parseInt(str) ? Thanks, Sudhir
EFH: Integer.parseInt(String) has to do much more work than String.valueOf(int). From the top of my head, I would predict the same result, but here is the surprise, -- Integer.parseInt() is actually faster than String.valueOf()!
Output from my machine, running jdk1.4.2 on Windows98: Integer.parseInt() test took 21040 ms String.valueOf() test took 24000 ms The "String temp = i + """ line is there to make it a fair test. I looked at the source code for both methods, and Integer.parseInt() does look more complex, so I am not sure what's at play here.
Joined: Oct 08, 2001
Even more interestingly, same test under jdk1.3.1 produces this: Integer.parseInt() test took 17520 ms String.valueOf() test took 13180 ms String.valueOf() almost twice faster in 1.3.1 compared to 1.4.2?
author and iconoclast
Microbenchmarks -- long loops that call the same tiny bit of code a million times -- are notoriously bogus with Hotspot, because of the way dynamic recompilation is done. You can't read too much into this test. But I did make a mistake here; parseInt() returns an int, while valueOf() returns a String. Allocating an object is costly, and since parseInt() doesn't need to allocate any, it's not surprising if it's faster. Change the program to use new Integer(temp) instead of parseInt(temp), and you're likely to see things go the other way.
Note also that in the original post, the plan is to compare the String to int. So I'm guessing that involves a String.valueOf() plus an equals() or compareTo(), or an Integer.parseInt() plus an == or -. So the parseInt() is looking even better, IMO, since == or - will probably be faster than equals() or compareTo(). But really, Sudhir - if you've got JProbe on the system, just try it both ways, and see which is faster. That will give you a more realistic picture of what effect this change will have on your system, they way you're currently using it - better than these microbenchmarks. Also consider - if the String can be parsed as an int, maybe you should do that when you first get the data, and store an int rather than a String. Then after that you can compare to other ints very quickly. This especially makes sense if you're going to do a lot of comparisons later (which sounds like it's the case, from your first post). You don't want to call either String.valueOf() or Integer.parseInt() more than once for the same data - converting the data when it's first read/loaded/whatever may be a good way to eliminate a bunch of redundant conversions later.
Yes, it seems as if the best strategy would *not* be to optimize the conversion, but to minimize the number of conversions you have to do. For example, you should take a look at your algorithm: What are you doing the comparisions for? Could their number be minimized somehow? If you can't minimize the number of conversions, you could try some kind of caching mechanism. That is, store already converted Strings in a HashMap together with the results of the conversion. Of course that would only help if the Strings are repeated several times.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus