How Expensive is Thread.getStackTrace()?

Question

In a logging system, every log output is done by a helper class with a method such as this one

public void debug(String message) {
    Logger logger = Logger.getLogger(getCallingClass());
    logger.debug(message);
}
...
public Class getCallingClass() {
/*
Calls Thread.getStackTrace() and back traces until the class on the stack trace 
!= this.getClass(). 
*/
    return classFound;
}

How expensive is this to run and could it have significant performance hits?

Answer 1

Yes, there is some overhead to this call, but in all likelyhood, you're going to do something like this:

public static boolean DEBUG_ON = true; //change this before your production build

then,

public void debug(String message){
  if(DEBUG_ON){
     //stack code here
  }

}

Which will cause you to not take the hit in your real code.

Even then, for exceptions, you're going to throw a whole stack traced Exception in your production build.

Note that if you are using a decent logging subsystem, they will probably already do something based on the logging level (in our log system, depending on the level, debug() is basically a no-op). Log4j and others have different ways of handling this.

Lastly, I'd say: Don't worry about it until it proves to be a real performance problem. Premature Optimization is the root of all evil :)

Answer 2

From what I recall, there's some impact in using Thread.getStackTrace() - especially with large stacks (such as when using in server-side or J2EE situations). You could try Throwable.getStackTrace() for better performance.

At any rate, calling those functions regularly (as opposed to doing so in an exception situation) will impact your app.