一个经常引用的依靠于logging的参数是可以计算的花费。这是一个合理的概念，一个适度的应用程序可能产生成千上万个日志请求。许多努力花在测量和调试logging的优化上。Log4j要求快速和弹性：速度最重要，弹性是其次。
用户应该注意随后的优化建议。
9.1 日志为禁用时，日志的优化
当日志被彻底的关闭，一个日志请求的花费等于一个方法的调用加上整数的比较时间。
在233mhz的Pentium II 机器上这个花费通常在5-50纳秒之间。
然而，方法调用包括参数构建的隐藏花费。
例如，对于logger cat，
logger.debug("Entry number: " + i + " is " + String.valueOf(entry));
引起了构建信息参数的花费，例如，转化整数i和entry到一个string，并且连接中间字符串，不管信息是否被输出。这个参数的构建花费可能是很高，它主要决定于被调用的参数的大小。
避免参数构建的花费应如下，
if(logger.isDebugEnabled() {
logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));
}
如果logger的debug被关闭这将不会招致参数构建的花费。另一方面，如果logger是debug的话，它将产生两次判断 logger是否能用的花费。一次是在debugenabled，一次是debug。这是无关紧要的，因为判断日志是否可用只占日志实际花费时间的约1%。
在Log4j里，日志请求在Logger 类的实例里。Logger 是一个类，而不是一个接口。这大量的减少了在方法调用上的弹性化的花费。
当然用户采用预处理或编译时间技术去编译出所有的日志声明。这将导致完美的执行成效。
然而因为二进制应用程序不包括任何的日志声明的结果，日志不可能对那个二进制程序开启。以我的观点，以这种较大的代价来换取较小的性能优化是不值得的。
9.2 当日志状态为启用时，日志的优化
这是本质上的优化logger的层次。当日志状态为开，Log4j依然需要比较请求的级别与logger的级别。然而，logger可能没有被安排一个级别；它们将从它们的father继承。这样，在继承之前，logger可能需要搜索它的祖先。
这里有一个认真的努力使层次的搜索尽可能的快。例如，子logger仅仅连接到它的存在的father logger。
在先前展示的BasicConfigurator 例子中，名为com.foo.bar 的logger是连接到根logger，因此绕过了不存在的logger com和com.foo。这将显著的改善执行的速度，特别是解析logger的层结构时。
典型的层次结构的解析的花费是logger彻底关闭时的三倍。
9.3 日志信息的输出时，日志的优化
这是主要花费在日志输出的格式化和发送它到它的输出源上。这里我们再一次的付出努力以使格式化执行的尽可能快。同appender一样。实际上典型的花费大约是100-300毫秒。
详情看org.apache.log4.performance.Logging。
虽然Log4j有许多特点，但是它的第一个设计目标还是速度。一些Log4j的组件已经被重写过很多次以改善性能。不过，投稿者经常提出了新的优化。你应该满意的知道，以SimpleLayout的配置执行测试已经展示了Log4j的输出同System.out.println一样快。