Avoiding extremely slow debugging?

Performance Tuning
#1

Hi anyone,

I’m debugging my jMonkeyEngine 3d application and achieve perhaps
3 frames per second, sometimes 1/15 frames per second.

When I run the application with the debugger disabled, I achieve
perhaps 100 or 200 fps.

I’m new to Java. How do people debug Java games? It seems
impossible – if I achieve a framerate of 1/15 fps now, then how
am I going to debug the application when it’s become 100
times more complex than as of today.

Is there perhaps a way to tell the Java debugger to debug only
my own source, not the middleware I’m using?
(I mean perhaps in the same way as with the -ea flag that can
enable assertions in certain packages only.)

(I’ve built jMonkeyEngine and jME-Physics_2 without debugging information;
nevertheless, when I run my application with debugging enabled I achieve
the above-mentioned rather unbearably slow framerate.)

(The game is currently sometimes 1 sometimes 100 boxes that falls on
a floor, bounce, and then rest. My own game does almost nothing;
jMonkeyEngine and jME-Physics_2 do all rendering and physics
computations. 3 fps with 1 box; perhaps 1/15 fps with 100 boxes.
I intended to use > 100 objects, more complicated than boxes…)

(I’m using Netbeans M10, Java 1.6 and Linux (Ubuntu). My machine
is a dual core 2 GB ram.)

Kind regards, Magnus

#2

Which profiler are you using.

#3

this seems to be the normal behaviour of Netbeans with debugging, but if your code is enough to debug itself you’d be able to face the lack of speed encountered. Plus the Java core seems to have difficulties to run more than one applications at a time, since the JRE can be limited on virtual memory on some systems, especially with the Windows system. Mac OS X and greater have it integrated in the core structure, e.g. I notice huge perf gaps with the graphics vertical synch’ between Win32 and MacOS X PPC. :-X
Perhaps this can change if the Java is distributed as a “consumer JRE” ( read on java.sun.com blogs ) as it would be smaller and more compact.

#4

With jdk1.5 and 1.6 I get a slowdown of 10% to a maximum of 40% with IDEA or Eclipse. This is for ‘normal’ applications and jME/jME Physics applications. If this really is a problem with Netbeans you should switch :-\

#5

-Xprof has minimum overhead and still allows the VM to inline methods (they’ll disappear from the stats though)

#6

Yes, if -Xprof works at all. I found that it doesn’t work anymore in Java6 for Swing applications (it simply hangs the app).
That said, I think the OP has problems debugging, not profiling.

#7

[quote=“erikd,post:6,topic:30552”]
Really? Who the hell is in charge of -Xprof at Sun?
As I understand it, it worked well in 1.4, was slow enough to be effectively useless in 1.5 and now is non-functional in 1.6?

To put it mildly, WTF?

#8

Well, it works as long as the application isn’t a swing app for whatever reason :-
Quite frustrating, really, but at least it seems to work better on 1.6 than it did in 1.5, if it works.

#9

The app doesn’t simply hang :wink: I waited once, and it just ran about 700 times slower than normal ;D

#10

Hanging, running 700 times slower… Same difference to me :slight_smile:
It is strange though that somehow Swing is triggering this…

#11

Hi all,

I think it seems to be an IDE issue, as `irrisor’ suggested. Sometimes the Netbeans 6 beta version Milestone 10 debugger runs extremely slowly, sometimes as quickly as one would expect it to do. Recently it started to run so very slowly when I modified the source code of a program and rebuilt it although one instance of it was running, and then I started a new instance (whilst the old was still running). This time however it was a Swing application; after this, Swing run extemely slowly (when debugging) until after a restart of Neteans 6 M10.

So, right now I feel I need not have posted about this. Thanks however for all answers :slight_smile:

( Hmm, if someone wants to, perhaps it could be appropriate that this thread be renamed so it does not accidentally cause anyone to believe that debugging Java apps is something inherently slow. I don’t know, perhaps append “not an issue” or “irrelevant” or “solved” to the title? )

( I choose Netbeans 6 beta version because I thought I wanted to use it’s Ruby support but I haven’t used Ruby at all and I guess I should’ve choosen a stable release instead :-/ )

if your code is enough to debug itself you’d be able to face the lack of speed encountered

I hope I’ll write lots of unit tests :slight_smile:

Which profiler are you using.

The Neteans 6 Milestone 10 debugger; I haven’t used the profiler.

Thanks,
Magnus