views:

942

answers:

9

For small logical programs that can be done in a text editor, for tracing I use the classic System.out.println().

I guess you all know how frustrating it is to use that in a block of high number of iterations. Why is it so slow? What's the reason behind it?

+25  A: 

This has nothing whatsoever to do with the JVM. Printing text to screen simply involves a lot of work for the OS in drawing the letters and especially scrolling. If you redirect System.out to a file, it will be much faster.

Michael Borgwardt
+1 for " drawing the letters and especially scrolling". Thanks
ZiG
Therefore it depends on the speed of the terminal. I once used a terminal with transparency and other eye-candy things. It looked nice but performed very badly, switching to another terminal solved these issues.
Philipp
+5  A: 

Ya, there is a huge amount of overhead in writing to the console. Far greater than that required to write to a file or a socket. Also if there are a large number of threads they are all contending on the same lock. I would recommend using something other that System.out.println to trace.

ng
+3  A: 

This has nothing to do with Java and JVM but with the console terminal. In most OSes I know writing in the console output is slow.

kgiannakakis
+6  A: 

This is very OS-dependent. For example, in Windows, writing to the console is a blocking operation, and it's also slow, and so writing lots of data to the console slows down (or blocks) your application. In unix-type OSes, writing to the console is buffered, so your app can continue unblocked, and the console will catch up as it can.

skaffman
+1  A: 

Some terminals just are faster than others. This may vary even within one operating system.

lhahne
+1  A: 

This might look as it doesn't directly answer your question, but my advice is to never use System.out for tracing ( if you mean by that a kind of debugging, in order just to see the advance of your app )

The problems with System.out for debugging are several :

  • once the app ends, when you close the console you'll loose the log

  • you'll have to remove those statements once your app is working properly ( or comment them ). Later if you want to reactivate them, you'll have to uncomment/comment again ... tedious

I recommend instead to use log4j and "watch" the log file, either with a tail command - there's also a Tail for Windows - either with an Eclipse plugin like LogWatcher.

Billy
A: 

The slowness is due the large amount of Java-Native transitions which happen on every line break or flush. If the iteration has to many steps, the System.out.println() isn't much of a help. If the iteration steps are not that important by themselves, you may call System.out.println() on every 10 or 100 steps only. You can also wrap the System.out into a BufferedOutputStream. And of course there is always the option to asynchronize the print via ExecutorService.

kd304
A: 

One interesting thing I've noticed about writing to the terminal (at least in Windows). Is it actually runs much much faster if the window is minimized. This is definitely closely tied with Michael Borgwardt's answer about drawing and scrolling. Really if you're logging enough to notice the slowdown you're probably better off writing to a file.

Hardwareguy
+1  A: 

Buffering can help enormously. Try this:

System.setOut( new PrintStream(new BufferedOutputStream(System.out)) );

But beware: you won't see the output appear gradually, but all in a flash. Which is great, but if you're using it for debugging, and the program crashes before it terminates, in some circumstances it's possible you won't see the text printed just before the crash. This is because the buffer wasn't flushed before the crash. It was printed, but it's still in the buffer, and didn't make it out to the console where you can see it. I remember this happening to me, in a puzzling debug session. It's best to occasionally flush explicitly, to make sure you see it:

System.out.flush();
13ren