CODEWITHSUNDEEP
javawhile-loop
Mark Tielemans
Mark Tielemans

Reputation: 1568

Adding System.out.println() slows down execution (a lot)?

I have a while loop with a switch statement:

while(true) {
        switch(state) {
        case LOADING :
            //THIS IS THE IMPORTANT PART
            //view loading screen (already set by default)
            contentPane.repaint();
            if(tick == 400000) {
                //state = GameState.MENU;
                System.out.println("Reached " + gameTick);
            }
            break;
        case MENU :
            //view menu
            break;
        //some other cases without content, left them out here
        }
        tick++;
        if(tick < 400000) {
                System.out.println(tick);
        }
        if(tick == Long.MAX_VALUE) {
            tick = 0;
        }
    }

Now this code executes just fine, it shows the loading screen (which has moving dots on it for as long as it's repaint is repeatedly called, so I know exactly when it stops), and the output counts from 1 to 400000 and on that number prints

399998
399999
Reached 400000

(last 3 lines of output)

The application goes fullscreen, and when I alt+tab out, the counter is usually somewhere around 130K, and I watch it move to 400K.

However, if I remove the if statement that prints this number:

if(tick < 400000) {
    System.out.println(tick);
}

The loading screen never moves, and when I alt + tab out, the 400K is already reached.

Also curious is that the loading screen has three 'appearance changes', one at 100 calls of it's paintComponent method, one at 200 calls and one at 300 calls, which resets the counter to 0. So basically, every 100 ticks it's supposed to have an appearance change. In the first case, with the if-statement, which has longer execution time, I see the changes but by far not as frequently as I'd expect. In the second case, I don't see them at all (I can imagine they'd happen too fast).

So my question is, what creates this quite big difference in execution time, and what causes the difference in the amount of times the paintComponent method seems to be called, and the 400.000 times the loop iterates?

All ideas appreceated.

Upvotes: 4

Views: 3408

Answers (5)

Peter Lawrey
Peter Lawrey

Reputation: 533560

Writing to the console, especially the MS-DOS console, is very very slow. You should try to keep the number of lines you write to the console to a minimum. If you have to write lots of data I suggest you write it to a file as it can be significantly faster.

I assume this is done in another thread and you are not tying up the GUI thread.

Upvotes: 5

Chase
Chase

Reputation: 1431

Any kind of interface is many many times slower then doing it without one. Be it console or graphical interface. This is mostly because of all the extra code that is required to access a graphical device. Not to mention hardware latency.

Upvotes: 1

Ashok Raj
Ashok Raj

Reputation: 454

try something like, 

tick++;
Thread.sleep(100);

and check whether your supposed change is happening.

Upvotes: 1

Sergey Kalinichenko
Sergey Kalinichenko

Reputation: 726669

Writing to console is a relatively time-consuming task, especially compared to doing nothing at all. This slows the execution down considerably. If you redirect the output to a file, your loop will be slower than without printing, but faster than with printing to console.

That is the cause of the big difference in execution speeds with and without printing.

Upvotes: 1

icza
icza

Reputation: 417797

The repaint() method does not repaint the component immediately, just signals the AWT/Swing system to repaint the component. 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.

Upvotes: 2

Related Questions