Sylvain Wallez wrote:
>
> Carsten Ziegeler wrote:
>
> > Sylvain Wallez wrote:
> >
> >>> Ok, that's a good point. Now log4j always claims to be
> the fastest
> >>> logging system, so I guess this isn't an issue anymore.
> >>
> >> Well, they claimed it at that time also. Log4J has some very good
> >> marketing ;-)
> >>
> > :) "Marketing is everything!"
> >
> > Ok, I just checked the code. It seems that logkit is doing
> one check
> > (testing ints) for "isDebugEnabled()" while log4j is doing two. Now
> > this shouldn't really affect the performance I think.
>
>
> Look further in the code: there's actually muuuuch more code
> behind it.
>
> public boolean isDebugEnabled() {
> if (repository.isDisabled(Level.DEBUG_INT)) {
> return false;
> }
> return Level.DEBUG.isGreaterOrEqual(this.getEffectiveLevel());
> }
>
> Yep, two tests. reposorit.isDisabled() is an interface call
> (slower than a class call) which leads to a simple test (see
> Hierarchy). Now let's dig deeper:
>
> public Level getEffectiveLevel() {
> for (Category c = this; c != null; c = c.parent) {
> if (c.level != null) {
> return c.level;
> }
> }
> }
>
> This crawls up the category tree up to finding one that has a
> level explicitely set! And for each call!!
>
> This reveals what is IMO an important design flaw in Log4J:
> logger priorities are checked a bazillion more times than
> they are changed.
>
> LogKit, on the other hand, takes into account the fact that
> logger priorities are checked a bazillion more times than
> they are changed.
> Therefore, it propagates priority changes on child loggers,
> meaning the crawl isn't needed and code required to check the
> priority is really
> minimal:
>
> public final boolean isDebugEnabled() {
> return m_priority.isLowerOrEqual( Priority.DEBUG ); }
>
> IMO, this makes a big difference when debug is disabled,
> especially with deep hierarchies as we have in Cocoon (need
> to take some of my copious free time to setup performance test cases).
>
> I consider this as an important design flaw in Log4J, which
> would require a good amount of work to be fixed.
>
Ok, this is all true - but considering performance it's imho neglectable
even if you consider that heavy xml parsing and stylesheet transformations
happen at the same time.
Carsten
