4

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.

Mark Tielemans
  • 1,528
  • 3
  • 20
  • 40

5 Answers5

5

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.

Matt
  • 70
  • 6
Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • Incredible (to me at least) how writing to the console appears so much slower than writing to a file.. Thanks for the insight anyway. However there is also the difference in times of iteration of the while loop and the amount paintComponent in contentPane is called. I just added a line which prints a counter of how often the paintComponent was executed, and it varies every time. In 400K while() iterations, the method seems to have been called 255 (lowest result) to 677 (highest result) times. It does relate to the amount of changes on the screen, which was 6. Could you per chance explain that? – Mark Tielemans Oct 03 '12 at 14:47
  • The GUI does its best to ignore spurious paint calls. As long as it more than the number actually needed and not too much it is fine. – Peter Lawrey Oct 03 '12 at 14:49
  • 1
    If you think about the amount of work required to print one character on the screen e.g. handling fonts, its not surprising its slower than writing to a file which doesn't need to do anything on a per character basis. What is surprising is that an MS-DOS window is so much slower than a Swing GUI or xterm (running Linux) on the same machine. – Peter Lawrey Oct 03 '12 at 14:51
  • Very useful background knowledge. Thanks for your answer, all clear now :). – Mark Tielemans Oct 03 '12 at 14:55
2

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.

icza
  • 389,944
  • 63
  • 907
  • 827
1

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.

Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
1

try something like, 

tick++;
Thread.sleep(100);

and check whether your supposed change is happening.

Ashok Raj
  • 444
  • 6
  • 25
  • Just added it, and the results were all working. Taking the print ln out made it take slightly shorter. Made it sleep(1) now which already slows it down significantly, to see if the two counters get somewhat nearer to eachother due to this. Will come back to this. – Mark Tielemans Oct 03 '12 at 14:53
  • In 400K iterations of the while loop, the paintComponent was now called 45662 times using sleep(1). This behaviour is explained by other answerers above. Thanks for your contribution! – Mark Tielemans Oct 03 '12 at 15:11
  • Yes, simply by adding `Thread.sleep(2)` to the while loop. I'm not supposed to use a certain amount of ticks to time anything anyway. This solution still relies on the compiler to limit the amount of times it calls paintComponent(), but if that gives me the highest refresh rate, I'll settle for that. – Mark Tielemans Oct 04 '12 at 16:02
1

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.

Chase
  • 1,419
  • 12
  • 17