Java System.out.print efficiency

Question

In the last few days, doing some competitive programming exercises, I found some solutions to some problems where instead of printing out text in the console in a for loop, they constructed a StringBuilder by appending the texts after each other. First I was confused but I gave it a try and made some benchmarks.

First Test: this is the classic way to print something on the screen:

class TestClass {

    public static void main(String args[]) throws Exception {
        double startTime = System.currentTimeMillis();

        //code
        for (int i = 0; i < 1000000; i++) {
            System.out.print("test");
        }
        //code
        double endTime = System.currentTimeMillis();
        String result = String.format("for loop: %.5f", (endTime-startTime) / 1000);
        System.out.print("\n"+result);
    }

}

Second test: and this is the enhanced version with StringBuilder:

class TestClass {

    public static void main(String args[]) throws Exception {
        double startTime = System.currentTimeMillis();

        //code
        StringBuilder sb = new StringBuilder();
        for (int i = 0; i < 1000000; i++) {
            sb.append("test");
        }
        System.out.print(sb);
        //code
        double endTime = System.currentTimeMillis();
        String result = String.format("for loop: %.5f", (endTime - startTime) / 1000);
        System.out.print("\n" + result);
    }

}

After running the tests several times(running them with Intel i5 6500 quad core 3.2 GHZ CPU, Win 10), the results are the following:

first test(for loop): 4,25s  
second test(StringBuilder): 0.23s

The results are not unexpected because out.print is synchronized so every time we call it, it will add some overhead. But being almost 20 times slower is somewhat strange.

My question is: is there a way we can improve this further?

Read this re: benchmarking - https://stackoverflow.com/questions/504103/how-do-i-write-a-correct-micro-benchmark-in-java — achAmháin, Aug 23 '18 at 16:11
console output is very slow because the text needs to be graphically rendered which requires a full redraw of the console screen. It does not use the GPU because that would add more dependencies so you have to wait for the CPU to redraw the screen. This means you will wait for the CPU to iterate over every pixel to correctly update the screen after each output. This is probably hundreds of thousands to millions of CPU cycles per call to the output function. — Chris Rollins, Aug 23 '18 at 16:28

xingbin · Accepted Answer · 2018-08-24T13:27:27.520

1

synchronized keyword should not be blamed in this case.

The first test case is slow, because System.out.print will bring frequent minimal I/O.

You can use BufferedWriter(it's write method is synchronized too) to reduce unecessary I/O:

BufferedWriter log = new BufferedWriter(new OutputStreamWriter(System.out));

//code
for (int i = 0; i < 1000000; i++) {
    log.write("test");
}

for loop: 0.21200

And, StringBuilder use byte[] for character storage internally. This byte array will grow when you keep appending contents, by copying old value into new byte[].

Give it a big enough capacity might bring some efficiency:

StringBuilder sb = new StringBuilder(1000000 * 10);

edited Aug 24 '18 at 13:27

answered Aug 23 '18 at 16:11

xingbin

27,410
9
53
103

the idea of initializing the `StringBuilder` with a concrete size is great, I tested it and it really improves performance – Csa77 Aug 23 '18 at 18:11
Are you sure `StringBuilder` capacity is measured in bytes and not chars? – DodgyCodeException Aug 24 '18 at 13:24
@DodgyCodeException yes, check the source code. – xingbin Aug 24 '18 at 13:26
Which version? In Java 8, StringBuilder is implemented using a `char[]`. – DodgyCodeException Aug 24 '18 at 13:44
@DodgyCodeException java 10.0.1 – xingbin Aug 24 '18 at 13:46
In version 10, Java Strings and StringBuilder are implemented using UTF-8, hence the `byte[]` data. But capacity is still measured in characters. – DodgyCodeException Aug 24 '18 at 13:47
@DodgyCodeException that's true. – xingbin Aug 24 '18 at 13:49
Actually, you're right. When using the COMPRESSED_STRINGS option (which is the default in Java 10), each char is compressed into a byte, so you can say capacity is indeed measured in bytes (unless you use non-ASCII chars which take up more than one byte). – DodgyCodeException Aug 24 '18 at 14:24

Java System.out.print efficiency

1 Answers1