Java - System.out effect on performance

Question

I've seen this question and it's somewhat similar. I would like to know if it really is a big factor that would affect the performance of my application. Here's my scenario.

I have this Java webapp that can upload thousands of data from a Spreadsheet which is being read per row from top to bottom. I'm using System.out.println() to show on the server's side on what line the application is currently reading.

- I'm aware of creating a log file. In fact, I'm creating a log file and at the same time, displaying the logs on the server's prompt.
Is there any other way of printing the current data on the prompt?

Answer 1

I was recently testing with (reading and) writing large (1-1.5gb) text-files, and I found out that:

PrintWriter out = new PrintWriter(new BufferedWriter(new OutputStreamWriter(new FileOutputStream(java.io.FileDescriptor.out), "UTF-8"), 512));
out.println(yourString);
//...
out.flush();

is in fact almost 250% faster than

System.out.println(yourString);

My test-program first read about 1gb of data, processed it a bit and outputted it in slightly different format.

Test results (on Macbook Pro, with SSD reading&writing using same disk):

• data-output-to-system-out > output.txt => 1min32sec
• data-written-to-file-in-java => 37sec
• data-written-to-buffered-writer-stdout > output.txt => 36sec

I did try with multiple buffer sized between 256-10k but that didn't seem to matter.

So keep in mind if you're creating unix command-line tools with Java where output is meant to be directed or piped to somewhere else, don't use System.out directly!

Answer 2

It can have an impact on your application performance. The magnitude will vary depending on the kind of hardware you are running on and the load on the host.

Some points on which this can translate to performance wise:

-> Like Rocket boy stated, println is synchronized, which means you will be incurring in locking overhead on the object header and may cause thread bottlenecks depending on your design.

-> Printing on the console requires kernel time, kernel time means the cpu will not be running on user mode which basically means your cpu will be busy executing on kernel code instead of your application code.

-> If you are already logging this, that means extra kernel time for I/O, and if your platform does not support asynchronous I/O this means your cpu might become stalled on busy waits.

You can actually try and benchmark this and verify this yourself.

There are ways to getaway with this like for example having a really fast I/O, a huge machine for dedicated use maybe and biased locking on your JVM options if your application design will not be multithreaded on that console printing.

Like everything on performance, it all depends on your hardware and priorities.