String.valueOf(int) vs "" + int

Overview

There are a number of reason prefer either

int i = ...
String s = "" + i;
String s = String.valueOf(i);

These include

  • simplicity
  • clarity
  • efficiency
  • performance

Personally I prefer efficiency for the developer as the performance difference is very, very small. IMHO, "" + i is also simpler and clearer, but that is a matter of taste.

Comparing the performance difference

public static void main(String... args) throws IOException {
    for (int i = 0; i < 3; i++) {
        long svo = perfStringValueOf();
        long qqp = perfQuoteQuotePlus();
        System.out.printf("String.valueOf took an average of %.3f us and \"\"+ took an average of %.3f us%n", svo / 1e3, qqp / 1e3);
    }
}

private static long perfStringValueOf() {
    long start = System.nanoTime();
    final int runs = 100000;
    String s;
    for (int i = 0; i < runs; i++) {
        s = String.valueOf(i * i);
        // ensure s is not optimised away
        if (s.length() < 1) throw new AssertionError();
    }
    long time = System.nanoTime() - start;
    return time / runs;
}

private static long perfQuoteQuotePlus() {
    long start = System.nanoTime();
    final int runs = 100000;
    String s;
    for (int i = 0; i < runs; i++) {
        s = "" + i * i;
        // ensure s is not optimised away
        if (s.length() < 1) throw new AssertionError();
    }
    long time = System.nanoTime() - start;
    return time / runs;
}

prints

String.valueOf took an average of 0.140 us and ""+ took an average of 0.243 us
String.valueOf took an average of 0.063 us and ""+ took an average of 0.058 us
String.valueOf took an average of 0.044 us and ""+ took an average of 0.058 us
This suggest that using String.valueOf will save 0.014 micro-seconds. However, using "" + will save you, the developer far, far more than that in time. (possibly a million times over)

As I have mentioned in previous article, if performance is really critical, you are better off writing the number as text to the direct ByteBuffer which will be written to the device where the text will be going. This creates no objects at all and is clearly OTT for 99% of use cases.

Comments

  1. Would have more sense just to decompile these examples:

    String s = String.valueOf(i * i);

    vs.

    String s = (new StringBuilder()).append("").append(i * i).toString();

    From that code, the difference is more than clear...

    ReplyDelete
  2. @Stas or

    String s = new StringBuilder().append("").append(String.valueOf(i * i)).toString();

    or

    String s = new StringBuilder().append("").append(Integer.toString(i * i)).toString();

    its hard to know there to stop. ;)

    ReplyDelete
  3. I did take a look at the code for JDK 5 classes.
    And my personal take is that using Integer.toString(int) will be better than using String.valueOf will inturn autobox the passed int to Integer object and then call toString on that object. The Integer toString instance method in turn calls toString static method.
    So by using Integer.toString(int) method directly we can save a couple of method calls.

    The time saved may be a few nano seconds but if we are doing such operations in loops then we can see performance gain.
    Also this is more of a code cleanliness issue.

    ReplyDelete
    Replies
    1. There's no autoboxing in `String.valueOf(int)` as it's overloaded for all primitive types. It directly calls `Integer.toString(i)`, so what you save is a single static method call which gets optimized away anyway.

      What's funny, my results are very different:
      https://dl.dropbox.com/u/4971686/published/maaartin/misc/IntToStringBenchmark.java
      benchmark ns
      StringValueOf 45.1
      IntegerToString 45.1
      QuoteQuotePlus 35.6

      Delete
  4. I agree its a code cleanliness issue. I happen to think "" + i is cleaner, but its a matter of taste.

    ReplyDelete

Post a Comment

Popular posts from this blog

Java is Very Fast, If You Don’t Create Many Objects

Low Latency Microservices, A Retrospective

Unusual Java: StackTrace Extends Throwable