18

One of my component is taking too much time to execute. It calls lots of services which in turn calls many dao methods. Now, is there any way to get the time taken by each method it is calling.
I don't want to write System.currentmillis before and after each method to calculate time taken as there are too many methods.
I think i may need to use interceptors or may be any profiler can do that. I am not sure, please help.

Paŭlo Ebermann
  • 73,284
  • 20
  • 146
  • 210
Rakesh Juyal
  • 35,919
  • 68
  • 173
  • 214
  • 1
    I believe most IDEs have profiler functionality built-in. – gigadot Feb 28 '11 at 08:11
  • Unfortunately I am a fan of Netbeans but I want to add that the times measured by profiler only give you te relative estimate. It is not the actual time spent on themethod. The profiler need to attach itself to method and that causes the extra overhead. – gigadot Feb 28 '11 at 17:46

3 Answers3

9

Use jvisualvm which should come with JDK (if I remember correctly). It's a GUI for your JVM, and has really nice functions. Check out its features there are some screenshots as well...

And you can follow these steps to integrate it as launcher in eclipse Steps to integrate in eclipse

shareef
  • 9,255
  • 13
  • 58
  • 89
posdef
  • 6,498
  • 11
  • 46
  • 94
  • i am using this but either i am unable to find where it shows the time taken by method or it doesn' show the time at all. – Rakesh Juyal Mar 01 '11 at 09:29
  • 1
    When you are running an application, you should activate cpu and memory profiler/sampler. Then you'll actively see hot spots. Once the execution is over it assembles a very neat report where you can oversee the different parts of the software that clogs up. (see: http://visualvm.java.net/images/profiler.jpg )Hope that helps. – posdef Mar 01 '11 at 10:27
1

You can use the Java Profiler in the NetBeans IDE.

Have a look here: http://netbeans.org/features/java/profiler.html

The Java VisualVM is another alternative: http://java.net/projects/visualvm/content/ . You can attach it to any running Java program, including ones you start through Eclipse.

Tom W
  • 578
  • 6
  • 16
1

Don't look at it as measuring time to find the problem.

Use its slowness to expose it. Just use the same method you would if it were an infinite loop.

That is, pause it a few times while it's being slow, and each time inspect the call stack of each thread. The guilty methods and lines of code will appear on multiple samples. Check the last paragraph of this post.

Here's more on how it works.

Community
  • 1
  • 1
Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135