[jsword-devel] Loggers

[Chris Burrell]

Yeah, i think that will help. I can do the first one. I'm not promising I
go through the whole code base to do the others.

Chris



On 5 February 2013 23:38, DM Smith <dmsmith at crosswire.org> wrote:

> Logger.doLogging needs to change to test the level against set level and
> bail if it is not going to be recorded.
>
> There will still be some building of messages outside. We can add a
> boolean shouldLog(logLevel) to help one determine on whether to construct a
> log message.
>
> Will that help?
>
> -- DM
>
> On Feb 5, 2013, at 6:22 PM, Chris Burrell <chris at burrell.me.uk> wrote:
>
> The 10% logging was debug logging, perhaps that was exacerbated during
> profiling, but i'd expect it to be exacerbated uniformly-sh.
>
> The JSword logger doesn't define a isDebugEnabled as far as I can see.
> Also, showLocation is true by default, so lots of work happens every time.
> The logger implementation seems to rely on the underlying functionality as
> to whether it is logged out to a screen/stream/file/etc. but by then all
> the work has been done.
>
> Due to the missing isDebugEnable type functions, JSword methods across the
> board presumably do quite a lot of concatenation before even calling the
> logger, i.e. passing a concatenation of parameters. (not sure whether the
> profiler would wrap that into the log call, or the caller method, probably
> the caller)
>
> Unfortunately, the third party is not in charge of showLocation. And can't
> change it as the moment except on a per logger basis. Perhaps it was the
> particular operation. It's partly because of String concatenations.
>
> Cheers
> Chris
>
>
>
> On 5 February 2013 23:04, DM Smith <dmsmith at crosswire.org> wrote:
>
>>
>> On Feb 5, 2013, at 3:37 PM, Chris Burrell <chris at burrell.me.uk> wrote:
>>
>> > Hi
>> >
>> > I was doing a bit of performance tuning for STEP earlier, to see how I
>> could speed up some of the searches. I found that possibly up to 10% of the
>> time could be spent logging.
>>
>> Seem strange that 10 percent of the time is managing errors. (You need to
>> look into configuring the logger to only log errors, if you aren't
>> already). Then the calls to logger are lightweight. Pretty much a no-op.
>>
>> There's a bug in changing the LogLevel and in specifying the logger
>> config. But I don't remember.
>>
>> >
>> > I'm guessing that's because of the bit that tries to throw an Exception
>> to capture the stack trace.
>>
>> We want that when we are handling errors. Maybe we don't want to do it
>> for all levels of logging. I.e. configure it.
>>
>> See the "showLocation" part of the getLogger() call.
>>
>> >
>> > Is there any reason why we're not using the java loggers directly?
>>
>> We are using the java loggers. We don't use it directly since we were
>> using a different logger before the java loggers.
>>
>> > Or why we're not using log4j (i see there's a not about keeping it
>> small)
>>
>> That's what we were using.
>>
>> The philosophy of JSword architecture is to:
>> define an abstract interface
>> create a basic implementation of the abstraction
>> use a plugin to define which implementation is being used. (Not used wrt
>> logging)
>>
>> By hiding behind the concrete abstraction, we were able to swap out
>> implementations.
>>
>> Hope this helps,
>>         DM
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20130206/b2bdcb4a/attachment.html>