AspectJ to calculate execution time

In this scenario, method1 calls method2.

There is a pointcut and advice defined on each of the method execution to calculate time taken by the method.
So,

   advice of `method1` prints 10 seconds; 

   advice of `method2` prints 6 seconds;

I want to print the time taken by method1 excluding the time taken by method2. That is I want 10-6 = 4 seconds as result

How can I acheive this using aspect ?

Expected : 4 seconds

Code snippet :

public int method1( String input ){
   User user = null;
   // something .. 
   method2(input, input2);
   return 100;
}

Here is the check method in aspect component:

@PointCut("....something correct")
public void endpoint (ProceedingJoinPoint pjp) throws Throwable {

@Around("endpoint")
public void timeTaken(ProceedingJoinPoint pjp) throws Throwable {
     
     //code to calcualte start time
     pjp.proceed();
     printf("the total time " : currentTime - startTime);
}

It might be possible, but complex to emulate a profiler by means of AOP. The reason is that you would need to calculate a method call tree and record it along with the execution times in a separate data structure. When logging, you would have to subtract execution times of everything in a subtree from the measured time. This would cost CPU cycles, memory and lots of maintenance work. One more issue is asynchronous code, i.e. multi-threading.

My recommendation is to take a step back and think about why you even think you need this. The only reason is that your method1 mixes (time-consuming) logic with calling other methods also containing (time-consuming) logic.

Have you ever heard about the Integration Operation Segregation Principle (IOSP)? It basically states that there are two types of methods:

• operations containing logic
• integrations only calling operations

If you apply this principle to your own code, you indirectly get the numbers you are interested in as a side effect.

So if you run this aspect

package de.scrum_master.aspect;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;

@Aspect
public class TimerAspect {
  @Around("execution(* *(..)) && within(de.scrum_master..*) && !within(TimerAspect)")
  public Object logExecutionTime(ProceedingJoinPoint joinPoint) throws Throwable {
    long startTime = System.nanoTime();
    try {
      return joinPoint.proceed();
    }
    finally {
      System.out.println(joinPoint + " -> " + (System.nanoTime() - startTime) / 1000000 + " ms");
    }
  }
}

against this application

package de.scrum_master.app;

public class Application {
  public static void main(String[] args) throws InterruptedException {
    new Application().method1("foo");
  }

  public int method1(String input) throws InterruptedException {
    Thread.sleep(300);
    method2(input, 11);
    Thread.sleep(100);
    return 100;
  }

  public void method2(String input, int i) throws InterruptedException {
    Thread.sleep(600);
  }
}

you get the problematic output you don't like:

execution(void de.scrum_master.app.Application.method2(String, int)) -> 604 ms
execution(int de.scrum_master.app.Application.method1(String)) -> 1009 ms
execution(void de.scrum_master.app.Application.main(String[])) -> 1010 ms

But if you refactor your application code according to the IOSP like this

package de.scrum_master.app;

public class Application {
  public static void main(String[] args) throws InterruptedException {
    new Application().integration("foo");
  }

  public int integration(String input) throws InterruptedException {
    operation1();
    operation2(input, 11);
    operation3();
    return 100;
  }

  private void operation1() throws InterruptedException {
    Thread.sleep(300);
  }

  public void operation2(String input, int i) throws InterruptedException {
    Thread.sleep(600);
  }

  private void operation3() throws InterruptedException {
    Thread.sleep(100);
  }
}

the application still does the same, but all logical and possible expensive operations are factored out into their own methods. operation2 is the same as method2 before, operation1 is the logic happening before and operation3 is the logic happening after and operation2. Now not only is your integration (formerly method1) cleaner and easier to read but also do you get separate timing logs for each operation:

execution(void de.scrum_master.app.Application.operation1()) -> 302 ms
execution(void de.scrum_master.app.Application.operation2(String, int)) -> 599 ms
execution(void de.scrum_master.app.Application.operation3()) -> 100 ms
execution(int de.scrum_master.app.Application.integration(String)) -> 1005 ms
execution(void de.scrum_master.app.Application.main(String[])) -> 1005 ms

Of course the Thread.sleep operations are just symbolical representations for whatever application logic you might have: if or switch - case statements, loops, external resource (file, database) handling, complex calculations or whatever.

Bottom line: Go refactor! Don't mix operations and integrations if you want to time, test, refactor, use them separately. Alternatively, use a profiler.