• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Which is faster .. String.valueOf(int) or Integer.parseInt(str)

 
sanju dharma
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24212
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Integer.parseInt(String) has to do much more work than String.valueOf(int). Parsing a string is a lot harder than generating one.
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24212
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic