commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Strange performance issues seen with Log.isDebugEnabled()
Date Thu, 26 Jun 2008 13:13:01 GMT
On 26/06/2008, simon.kitching@chello.at <simon.kitching@chello.at> wrote:
> Jörg Schaible schrieb:
>
>
> > Jean-Philippe Daigle wrote:
> > [snip]
> >
> >
> > > Ah, so there's one more thing I hadn't tried, which I just did, and
> > > explained a bit of the situation: completely removing the
> > > logging block
> > > (don't check isDebugEnabled(), don't call .debug(), etc.
> > >
> > > Removing the whole logging block results in getting the same slow
> > > throughput case that I was blaming on isDebugEnabled().
> > >
> > > Replacing it with just this assignment (to a public var so it's not
> > > optimized away):
> > >   _dbg_str = String.format("appack>>> id=%s res=%s", id, ack_r);
> > >
> > > Gives me the fast throughput case. Wow. So apache commons logging is
> > > blameless, what determines whether you get the fast or the
> > > slow message
> > > throughput case is actually _slowing down the thread calling the
> > > ackMessage() method_. Slowing down this frequently-called method with
> > > useless String.format() work results in more than double the
> > > throughput.
> > > I have no idea why (it's counterintuitive), I suspect I need
> > > to get more
> > > visibility into the interactions between threads here.
> > >
> > > Thanks to everyone that read this thread, looks like the problem's
> > > somewhere else in my code. (Though if you DO have any suggestions that
> > > could explain what I'm seeing, let me know, even if this is
> > > no longer a
> > > logging issue :) )
> > >
> > >
> >
> > Can you stip it down to detect the real call that is responsible for the
> speed-up?
> >
> > 1/ _dbg_str = ack_r.toString();
> >
> >  or
> > 2/ _dbg_str = String.valueOf(id);
> >
> >  or even
> >
> > 3/ ack_r.toString();
> >
> > alone?
> >
> > What's implemented with ack_r.toString() ? What kind of implementation is
> ack_r ? A proxy ?
> >
> >
>
>  Yes, good point. I missed that ack_r.toString will be triggered.
>
>  I wonder what happens if you replace the String.format call with just this:
>   synchronized(this) {
>    ++dummy;
>   }
>  where dummy is a public int member, just so the synchronized block isn't
> optimised away. The synchronization operation will have a number of
> side-effects, including entering the OS kernel, flushing CPU caches and
> allowing the OS scheduler to run.

Or perhaps:

public volatile long dummy;

...


dummy++;

If you are running Java 1.5+ this will cause memory flushing; not sure
about the effects on the OS scheduler.

>  Regards,
>  Simon
>
>
>
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail:
> user-unsubscribe@commons.apache.org
>  For additional commands, e-mail: user-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message