Je me pose une grande question: (utilisant la lib commons d'apache)
 

est t'il plus couteux que de tester avant:

 
ou alors de toute facon dans la fonction de log le test sera fait assez tot?
J'ai commence a regarder dans le source code de la lib mais je m'y perd un peu avec tout ces appels d'implementation.
 
 
 

Je me trompe ou le titre prête à confusion avec le post : log4j != jakarta commons logging.
 
Je ne sais pas pour common logging, mais pour log4j il y a ça :
http://logging.apache.org/log4j/1. [...] erformance
 
En pratique, on ne teste que le niveau debug.

La question n'est pas là. Le problème, c'est que LOG.debug(expression) (ou .info) implique que expression soit évaluée. Il sera toujours trop tard quand le test "dois-je logguer" sera réalisé par log4j.
 
Je me tracasserais pas trop pour ce genre de micro-optimisations. En général, je teste isDebugEnabled si l'expression à logger est relativement lourde à évaluer, ou si elle se situe dans une boucle.
 
Dans les autres cas, je ne suis pas certain que c'est là que tu auras des bottlenecks.  
 
Si tu veux vraiment optimiser sans rendre ton code illisible, prévoit une transformation de ta source lors du build pour remplacer tous les LOG.debug en if (LOG.isDebugEnabled) LOG.debug, dont l'overhead est très faible.

Effectivement me suis trompé dans le titre, c'est commons que j'utilise. Merci pour le lien, j'imagine que le comportement à ce niveau doit etre le meme entre commons logging et log4j.

Hum pas con ton idée de pré-formater le code avant build, faut que je regarde comment on fait ça dans Eclipse.
Donc sinon je comprends que ça peut valoir le coup pour le niveau debug (ou plus bas) vu qu'il y en a génaralement bien plus que les autres, et donc eviter un certain nombre d'evaluation des parametres.
Comme c'est une application qui mouline assez vite, je ferais le test au moins pour les appel a debug avec evaluation un chouilla couteuse.

En tout cas c'est bien plus clair pour moi maintenant, merci à vous deux!