A mai Log4j2 és Slf4j/Logback rendszerek eléggé jó teljesítményt tudnak nyújtani, főleg aszinkron loggerrel vagy appenderrel. Ezeknél szintén nem probléma a nem aktív logger használata sem, mert a paraméteres API-t (vagy Log4j2 2.4-től kezve lambdát) használva nem kell a logüzenetet összeállítana addig, amíg az appenderekre ki nem kerül ténylegesen.
Az általad is említett függvény naplózására meg vagy kézzel (fv elején és végén is log hívás), vagy AOP-vel tennék naplózást, itt sincs jelentős teljesítményvesztés, megfelelő AOP lib használata esetén.
Exception naplózása pedig kardinális mindig, az egyéb jellegű naplózásoktól függetlenül is. Sőt, ha nem valami managed konténerben fut az alkalmazásom, akkor a Thread.setDefaultUncaughtExceptionHandler-t is beállítom, hogy naplózza a véletlenül el nem kapott exception-öket.
Cserébe a naplózást "sztenderd" módon lesz megoldva, aminek rengeteg előnye van (konfigurálhatóak tetszőlegesen, illetve összecsatornázható a sok komponens logkimenete, stb).
Szóval jó kis gyakorlás az általad írt naplózó rendszer, de egyszerűen nem éri meg használni.
Megj: pont nemrég foglalkoztam azzal, hogy egy borzasztóan rosszul megírt 0-24-ben működő szoftverben kellett bonyolult hibákat nyomozni. A program 6 féle naplózást használt (System.out, log4j 1.2, JDK logging, slf4j API, WebLogic Application logger, custom adatbázis-alapú logger), és gyakorlatilag konfigurálhatatlan volt a naplózása. Nagy nehezen sikerült az egészet logback-re irányítani, innentől kezdve az alkalmazás újraindítása nélkül is újrakonfigurálható a naplózás tetszőlegesen. Nem beszélve a teljesítményről: a 6-os JDK logging és a log4j 1.2 után, pusztán a backend logback-re állításával érezhetően és mérhetően javult egyes processzek teljesítménye.