Why is System.out.println so slow?

system out println
system.out.println vs logger performance
system.out.println syntax in java
alternative for system out println in java
println() method in java
use of + in system.out.println in java
java fast system out
stdout vs system out

Is this something common to all programming languages? Doing multiple print followed by a println seems faster but moving everything to a string and just printing that seems fastest. Why?

EDIT: For example, Java can find all the prime numbers up to 1 million in less than a second - but printing then all out each on their own println can take minutes! Up to a 10 billion can hours to print!

EX:

package sieveoferatosthenes;
public class Main {
    public static void main(String[] args) {
        int upTo = 10000000;
        boolean primes[] = new boolean[upTo];
        for( int b = 0; b < upTo; b++ ){
            primes[b] = true;
        }
        primes[0] = false;
        primes[1] = false;

        int testing = 1;

        while( testing <= Math.sqrt(upTo)){
            testing ++;
            int testingWith = testing;
            if( primes[testing] ){
                while( testingWith < upTo ){
                    testingWith = testingWith + testing;
                    if ( testingWith >= upTo){
                    }
                    else{
                        primes[testingWith] = false;
                    }

                }
            }
        }
        for( int b = 2; b < upTo; b++){
            if( primes[b] ){
                System.out.println( b );
            }
        }
    }
}

println is not slow, it's the underlying PrintStream that is connected with the console, provided by the hosting operating system.

You can check it yourself: compare dumping a large text file to the console with piping the same textfile into another file:

cat largeTextFile.txt
cat largeTextFile.txt > temp.txt

Reading and writing are similiar and proportional to the size of the file (O(n)), the only difference is, that the destination is different (console compared to file). And that's basically the same with System.out.


The underlying OS operation (displaying chars on a console window) is slow because

  1. The bytes have to be sent to the console application (should be quite fast)
  2. Each char has to be rendered using (usually) a true type font (that's pretty slow, switching off anti aliasing could improve performance, btw)
  3. The displayed area may have to be scrolled in order to append a new line to the visible area (best case: bit block transfer operation, worst case: re-rendering of the complete text area)

println() then it is possible to get a good performance boost by using an alternative to do the console output. By default, System.out.print() is only line-​buffered and  println is not slow, it's the underlying PrintStream that is connected with the console, provided by the hosting operating system. You can check it yourself: compare dumping a large text file to the console with piping the same textfile into another file:

System.out is a static PrintStream class. PrintStream has, among other things, those methods you're probably quite familiar with, like print() and println() and such.

It's not unique to Java that input and output operations take a long time. "long." printing or writing to a PrintStream takes a fraction of a second, but over 10 billion instances of this print can add up to quite a lot!

This is why your "moving everything to a String" is the fastest. Your huge String is built, but you only print it once. Sure, it's a huge print, but you spend time on actually printing, not on the overhead associated with the print() or println().

As Dvd Prd has mentioned, Strings are immutable. That means whenever you assign a new String to an old one but reusing references, you actually destroy the reference to the old String and create a reference to the new one. So you can make this whole operation go even faster by using the StringBuilder class, which is mutable. This will decrease the overhead associated with building that string you'll eventually print.

Since println() is a synchronized method, so when multiple threads are passed could lead to the low-performance issue. System.out.println() is a slow operation as  System.out.println() is a slow operation as it incurs heavy overhead on the machine compared to most IO operations. There is an alternative way of performing output operations by invoking PrintWriter or the BufferedWriter class. They are fast as compared to the println() of the PrintStream class. Related Articles: Difference between print() and

I believe this is because of buffering. A quote from the article:

Another aspect of buffering concerns text output to a terminal window. By default, System.out (a PrintStream) is line buffered, meaning that the output buffer is flushed when a newline character is encountered. This is important for interactivity, where you'd like to have an input prompt displayed before actually entering any input.

A quote explaining buffers from wikipedia:

In computer science, a buffer is a region of memory used to temporarily hold data while it is being moved from one place to another. Typically, the data is stored in a buffer as it is retrieved from an input device (such as a Mouse) or just before it is sent to an output device (such as Speakers)

public void println()

Terminate the current line by writing the line separator string. The line separator string is defined by the system property line.separator, and is not necessarily a single newline character ('\n').

So the buffer get's flushed when you do println which means new memory has to be allocated etc which makes printing slower. The other methods you specified require lesser flushing of buffers thus are faster.

It really depends - compared to what? What else does the application do? There are some applications where yes, System.out.println() will slow  So if you call repaint() fast 10 times, there is a good chance it will only be repainted once. Now if you look at your loop, it does nothing that would take long (note that repaint() does not repaints). If you add a System.out.println() call in the loop, it will significantly increase the work to be done inside your loop.

Take a look at my System.out.println replacement.

By default, System.out.print() is only line-buffered and does a lot work related to Unicode handling. Because of its small buffer size, System.out.println() is not well suited to handle many repetitive outputs in a batch mode. Each line is flushed right away. If your output is mainly ASCII-based then by removing the Unicode-related activities, the overall execution time will be better.

Let's see this in action in an improved checkSpeed method: public void checkSpeed() { if (speed - 200) System.out.println(speed + "MHz is too slow"); else  Either way ~750ms sound ridiculously slow. No matter how computational complex println! is, i can literally make trillions of operations in that timespan. I guess something in the i/o chain between your executable and the output of your monitor is very slow.

If you're printing to the console window, not to a file, that will be the killer.

Every character has to be painted, and on every line the whole window has to be scrolled. If the window is partly overlaid with other windows, it also has to do clipping.

That's going to take far more cycles than what your program is doing.

Usually that's not a bad price to pay, since console output is supposed to be for your reading pleasure :)

Most useful programs require input and provide output so it can interact with the user. A few programs have or arguing. It's just information you are giving to System.out.println so it knows what to print. This is considered slow. It would be​  I heard that using System.out.println for logging purposes is a very bad practice and this may force the server to fail.. I don't use this approach but I am very interested in knowing why System.out.println could make so trash things when used in backend code.

Printing logs to the console is slower and very slow than printing to files. System.out.println And write to /dev/stdout It takes an order of  As to why Google would do this, Peterson wrote, "I assume Google has metrics showing that the Polymer redesign increases Firefox and Edge user engagement more than the slow polyfills hurt it

Though, Java has pretty handy System.out.println() methods to print something on All of this information can be really useful while debugging  why is windows 10 so slow Hello ,first of all i would advise anyone still considering the upgrade to Windows 10 DO NOT DO IT !! . If you are really desperate to try it out wait a few weeks or maybe months until a lot of problems with it are solved .If you install it now be prepared for the real possibility of a lot of problems .

System.out.println("UTIL ArrayList Milliseconds Taken = " + (System. Millis(); for (int slow = 0; slow & 1000000; slow #4) { fArList.get(slow); 188 FAST FastArrayList Milliseconds Taken = 0 So, the FastArrayList does actually work quite fast  Emma Witman/Business Insider Although some extensions can slow Chrome down, others are specifically aimed at improving your browser's speed.

Comments
  • Care to explain? I've always found println to be quite fast...
  • @DasWood "Seems"? Please present some benchmarks (code + timings).
  • It tends to be fast on *nix, slow on windows. In other words, it's the console implementations of those OSes that's the factor here.
  • Bench the example I paste with printing commented out. Bench again with it not. HUGE difference and it is only running through the number line once, not 9999998 times like the actual sieve.
  • Do you mean println vs nothing, or println vs print? They are very different questions.
  • Ok, then why is the underlying io operations so slow?
  • is it theoretically possible to optimize this in case of console output? E.g. to buffer output to be displayed up to say "one page", so scrolling only has to be performed once? I know that the responsibility of output buffering actually lies within the console implementation, just curious.
  • Between your answer and Alfred's the answer given is very complete. Thanks.
  • Creating the Strings is not the problem. If you just create the Strings by don't print them it will run close to the same speed.
  • See my reply which shows it takes very little time to toString or write to a file, many orders of magnitude longer to write to the console (even when just displaying a file with the values)
  • I mentioned that this will make it go "even faster", which it will for something of the order of 10 billion string concatenations, as the OP mentioned. I in no way stated that it's the creation of the String that's taking the most time.
  • Buffering to a file or console is the same (they are both file descriptors underneath) however a file is as much as 300x faster, meaning the buffering cost is a fairly small piece.
  • @Peter I think you are right about that. The disc has much higher throughput compared to the screen?