<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Logger.doLogging needs to change to test the level against set level and bail if it is not going to be recorded.<div><br></div><div>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.</div><div><br></div><div>Will that help?</div><div><br></div><div>-- DM</div><div><br><div><div>On Feb 5, 2013, at 6:22 PM, Chris Burrell <<a href="mailto:chris@burrell.me.uk">chris@burrell.me.uk</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">The 10% logging was debug logging, perhaps that was exacerbated during profiling, but i'd expect it to be exacerbated uniformly-sh.<div><br></div><div style="">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.</div>
<div style=""><br></div><div style="">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)</div>
<div><br></div><div style="">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.</div>
<div style=""><br></div><div style="">Cheers</div><div style="">Chris</div><div style=""><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 5 February 2013 23:04, DM Smith <span dir="ltr"><<a href="mailto:dmsmith@crosswire.org" target="_blank">dmsmith@crosswire.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Feb 5, 2013, at 3:37 PM, Chris Burrell <<a href="mailto:chris@burrell.me.uk">chris@burrell.me.uk</a>> wrote:<br>
<br>
> Hi<br>
><br>
> 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.<br>
<br>
</div>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.<br>
<br>
There's a bug in changing the LogLevel and in specifying the logger config. But I don't remember.<br>
<div class="im"><br>
><br>
> I'm guessing that's because of the bit that tries to throw an Exception to capture the stack trace.<br>
<br>
</div>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.<br>
<br>
See the "showLocation" part of the getLogger() call.<br>
<div class="im"><br>
><br>
> Is there any reason why we're not using the java loggers directly?<br>
<br>
</div>We are using the java loggers. We don't use it directly since we were using a different logger before the java loggers.<br>
<div class="im"><br>
> Or why we're not using log4j (i see there's a not about keeping it small)<br>
<br>
</div>That's what we were using.<br>
<br>
The philosophy of JSword architecture is to:<br>
define an abstract interface<br>
create a basic implementation of the abstraction<br>
use a plugin to define which implementation is being used. (Not used wrt logging)<br>
<br>
By hiding behind the concrete abstraction, we were able to swap out implementations.<br>
<br>
Hope this helps,<br>
DM<br>
<br>
<br>
</blockquote></div><br></div>
</blockquote></div><br></div></body></html>