commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Vandahl>
Subject Re: [jcs] logging
Date Mon, 02 Jun 2014 18:51:49 GMT
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:

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:
For additional commands, e-mail:

View raw message