Question

I am writing a simple checkers game in Java. When I mouse over the board my processor ramps up to 50% (100% on a core).

I would like to find out what part of my code(assuming its my fault) is executing during this.

I have tried debugging, but step-through debugging doesn't work very well in this case.

Is there any tool that can tell me where my problem lies? I am currently using Eclipse.

Was it helpful?

Solution

This is called "profiling". Your IDE probably comes with one: see Open Source Profilers in Java.

OTHER TIPS

Use a profiler (e.g yourkit )

Profiling? I don't know what IDE you are using, but Eclipse has a decent proflier and there is also a list of some open-source profilers at java-source.

In a nutshell, profilers will tell you which part of your program is being called how many often.

I don't profile my programs much, so I don't have too much experience, but I have played around with the NetBeans IDE profiler when I was testing it out. (I usually use Eclipse as well. I will also look into the profiling features in Eclipse.)

The NetBeans profiler will tell you which thread was executing for how long, and which methods have been called how long, and will give you bar graphs to show how much time each method has taken. This should give you a hint as to which method is causing problems. You can take a look at the Java profiler that the NetBeans IDE provides, if you are curious.

Profiling is a technique which is usually used to measure which parts of a program is taking up a lot of execution time, which in turn can be used to evaluate whether or not performing optimizations would be beneficial to increase the performance of a program.

Good luck!

1) It is your fault :)

2) If you're using eclipse or netbeans, try using the profiling features -- it should pretty quickly tell you where your code is spending a lot of time.

3) failing that, add console output where you think the inner loop is -- you should be able to find it quickly.

Yes, there are such tools: you have to profile the code. You can either try TPTP in eclipse or perhaps try JProfiler. That will let you see what is being called and how often.

Use a profiler. There are many. Here is a list: http://java-source.net/open-source/profilers. For example you can use JIP, a java coded profiler.

Clover will give a nice report showing hit counts for each line and branch. For example, this line was executed 7 times.

Plugins for Eclipse, Maven, Ant and IDEA are available. It is free for open source, or you can get a 30 day evaluation license.

If you're using Sun Java 6, then the most recent JDK releases come with JVisualVM in the bin directory. This is a capable monitoring and profiling tool that will require very little effort to use - you don't even need to start your program with special parameters - JVisualVM simply lists all the currently running java processes and you choose the one you want to play with.

This tool will tell you which methods are using all the processor time.

There are plenty of more powerful tools out there, but have a play with a free one first. Then, when you read about what other features are available out there, you'll have an inking about how they might help you.

This is a typically 'High CPU' problem.

There are two kind of high CPU problems

a) Where on thread is using 100% CPU of one core (This is your scenario)

b) CPU usage is 'abnormally high' when we execute certain actions. In such cases CPU may not be 100% but will be abnormally high. Typically this happens when we have CPU intensive operations in the code like XML parsing, serialization de-serialization etc.

Case (a) is easy to analyze. When you experience 100% CPU 5-6 thread dumps in 30 sec interval. Look for a thread which is active (in "runnable" state) and which is inside the same method (you can infer that by monitoring the thread stack). Most probably that you will see a 'busy wait' (see code below for an example)

while(true){
  if(status) break;
  // Thread.sleep(60000); // such a statement would have avoided busy wait
}

Case (b) also can be analyzed using thread dumps taken in equal interval. If you are lucky you will be able to find out the problem code, If you are not able to identify the problem code by using thread dump. You need to resort to profilers. In my experience YourKit profiler is very good.

I always try with thread dumps first. Profilers will only be last resort. In 80% of the cases we will be able to identify using thread dumps.

Or use JUnit test cases and a code coverage tool for some common components of yours. If there are components that call other components, you'll quickly see those executed many more times.

I use Clover with JUnit test cases, but for open-source, I hear EMMA is pretty good.

In single-threaded code, I find adding some statements like this: System.out.println("A: "+ System.currentTimeMillis()); is simpler and as effective as using a profiler. You can soon narrow down the part of the code causing the problem.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top