一個經常引用的依靠于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一樣快。