On 01.06.14 21:26, Romain Manni-Bucau wrote: > Hi > > I have two main point to discuss regarding the logging: > 1) LogHelper stuffI committed. Idea was to cache isDebugEnabled to get a if > (boolean) complexity and not go through the logging framework which can > imply several layers (filter, appender, handler, logger...) for nothing and > slow down caching (which has more perf constraints than other backends. > This really depends on the logger you use but we can't suppose it is the > one we benched against. Solutions I see: a) keep LogHelper, b) remove logs > (some are useless I think), 3) other?
Remember what I said about use cases. You have your one-and-only use case in your mind. Others may have other use cases, accept dependencies, need debugging. A quick scan of the net shows several places where the performance issue has been discussed. Examples: http://learnertobeginner.blogspot.de/2010/06/how-to-use-isdebugenabled-effectly.html or http://logging.apache.org/log4j/2.x/performance.html Both suggest that the isDebugEnabled() call can be neglected for most of the cases. It is not ConcurrentHashMap you are competing with. Create a benchmark, run it and see for yourself. Logging is the least of our performance issues, I promise. > 2) logger api used. ATM we use [logging] but it will surely be an issue for > TomEE when integrated ([logging] is the less integrated framework - > compared to JUL or SLF4J where we don't have the choice at all) and I think > we'd be happy to remove it from the container to let it be application > oriented if we can. Any idea to make it hurtless? This doesn't urge and > doesn't block anything but if someone has an awesome idea it would be > welcomed ;) I'm not sure I understand what you want to tell me. Do you consider it good manners to jump into a community and tell them right away how shitty their logging framework is? My experiences with JUL are no better by the way. That said, I don't really care about the logging framework. Move to JUL if you believe it's faster. But please avoid shooting yourself in the foot by prematurely optimizing things and removing important features. Bye, Thomas. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
