Question: A lot of times while writing applications, I wish to profile and measure the time taken for all methods in a **stacktrace**. What I mean is say:

```
Method A --> Method B --> Method C ...

```

`A` method internally calls `B` and it might call another. I wish to know the time taken to execute inside each method. This way in a web application, I can precisely know the percentage of time being consumed by what part of the code.

To explain further, most of the times in spring application, I write an aspect which collects information for every method call of a class. Which finally gives me summary. But I hate doing this, its repetitive and verbose and need to keep changing regex to accommodate different classes. Instead I would like this:

```
@Monitor
public void generateReport(int id){
...
}

```

Adding some annotation on method will trigger instrumentation api to collect all statistics of time taken by this method and any method later called. And when this method is exited, it stops collection information. I think this should be relatively easy to implement.

The questions is: Are there any reasonable alternatives that lets me do that for general java code? Or any quick way of collection this information. Or even a spring plugin for spring applications?

PS: Exactly like [XRebel](http://zeroturnaround.com/software/xrebel/), it generates beautiful summaries of time take by the security, dao, service etc part of code. But it costs a bomb. If you can afford, you should definitely buy it.

Answer: 
This is the exact reason why I built the open source tool [stagemonitor](http://www.stagemonitor.org/), which uses Byte Buddy to insert profiling code. If you want to monitor a web application you don't have to alter or annotate your code. If you have a standalone application, there is a [`@MonitorRequests`](https://github.com/stagemonitor/stagemonitor/wiki/Integrate-stagemonitor-into-non-servlet-based-applications#declaratively) annotation you can use.

[![Stagemonitor Call Tree](https://i.stack.imgur.com/TTFkg.png)](https://i.stack.imgur.com/TTFkg.png)
You say you want to know the percentage of time taken within each routine on the stack.

I assume you mean *inclusive* time.

I also assume you mean *wall-clock* time, on the theory that if one of those lower-level callees happens to do some I/O, locking, etc., you don't want to be blind to that.

So a stack-sampling profiler that samples on wall-clock time will be getting the right kind of information.

The percentage time that A takes is the percentage of samples containing A, same for B, etc.

To get the percentage of A's time used by B, it is the percentage of samples containing A that happen to have B at the next level below.

The information is all in the stack samples, but it may be hard to get the profiler to extract just the information you want.

You also say you want *precise* percentage.
That means you also need a large number of stack samples.
For example, if you want to shrink the uncertainty of your measurements by a factor of 10, you need 100 times as many samples.

In my experience finding performance problems, I am willing to tolerate an uncertainty of 10% or more, because my goal is to find big wastage, not to know with precision how bad it is.
So I take samples manually, and look at them manually.
In fact, if you look at the statistics, you only have to see something wasteful on as few as *two* samples to know it's bad, and the fewer samples you take before seeing it twice, the worse it is.
(Example: If the problem wastes 30% of time, it takes on average 2/30% = 6.67 samples to see it twice. If it wastes 90% of time, it only takes 2.2 samples, on average.)