Java: Netbeans debugging session works faster than normal run

Question

Hello,

I'm making Braid in Netbeans 6.7.1.

Computer Spec:

Windows 7
Running processes: 46
Running threads: +/- 650
NVidia GeForce 9200M GS
Intel Core 2 Duo CPU P8400 @ 2.26Ghz

Game-spec with normal run:

Memory: between 80 MB and 110 MB
CPU: between 9% and 20%
CPU when time rewinding: 90%

The same values for the debugging session, except when I rewind the time: CPU: 20%.

Is there any reason for? Is there a way to reach the same performance with a normal run.

This is my repaint code:

 @Override
 public void repaint()
 {
     BufferStrategy bs = getBufferStrategy(); // numBuffers: 4
     Graphics g = bs.getDrawGraphics();
     g.setColor(Color.BLACK);
     g.fillRect(-1, -1, 2000, 2000);
     gamePanel.paint(g.create(x, y, gameDim.width, gameDim.height));
     bs.show();
     g.dispose();
     Toolkit.getDefaultToolkit().sync();
     update(g);
 }

The game runs in fullscreen (undecorated + frame.size = screensize)

Martijn

Answer 1

Can you post the JVM arguments you're using when running in debug mode and in "normal" mode?

That's the only reason I can think right now.

Answer 2

Which framework do you use? Or did you write one yourself? In the latter case, are you using System.currentTimeMillis() or System.nanoTime() to limit the FPS?

Debugmode may change the resolution of the OS interrupt rate under Windows and therefore changing the resolution of System.currentTimeMillis() too.

I had a similiar case in which my game did run faster when using VisualVM. Using System.nanoTime() instead of System.currentTimeMillis() to calculate the value for Thread.sleep() fixed it.

You can read more on this topic here: http://blogs.sun.com/dholmes/entry/inside%5Fthe%5Fhotspot%5Fvm%5Fclocks

Answer 3

Are you running the debugger actively stepping through the code, or are you running it with a debugger attached, but not hitting breakpoints?

It's a silly thought, but if you're debugging one of the intensive threads, you're effectively limiting the amount of CPU time being used because it's waiting on input from you, no?

Answer 4

The repaint() method is cheap because multiple requests are coalesced before being processed. I'll take a guess that under the debugger more repaints are being coalesced into actual calls to paint().

Try keeping a counter that is updated on each call to paint() or paintComponent(). If I'm right, you should see less calls when running under the debugger.