Constructing the logging strings is half of the problem. The amount of
garbage they will generate will result in significantly more time in
garbage collection pauses.
Unless you figure out a way to mimic lazy evaluation you have to live with
the isLoggable predicates. varargs are not an option either because they
also create garbage.
On Mar 22, 2012 8:11 AM, "Marco Schulze" <marco.c.schulze at gmail.com> wrote:
>
>
> On 22-03-2012 08:50, Matthew Toseland wrote:
>
>> On Wednesday 21 Mar 2012 21:18:37 Marco Schulze wrote:
>>
>>> There are basically two big concerns regarding logging in fred:
>>>
>>> - Readability and code clutter, which was my original questioning;
>>> - Raw throughput, as raised by toad.
>>>
>>> Point 1 could mostly be solved by removing any traces of logMINOR and
>>> logDEBUG on all but the few places where generating messages to be
>>> logged brings noticeable slowdown. That'd be enough, but, personally,
>>> the mess that the logging backend is does warrant a replacement.
>>> According to toad, the current system needs log{MINOR,DEBUG} to function
>>> in a timely manner. Based on this, I think we all agree a replacement is
>>> desirable.
>>>
>>> Logging has a few additional requirements:
>>>
>>> - Log rotation (possibly live);
>>> - Reentrant;
>>> - Per-class filtering;
>>> - Specific information in log (class-name, for example).
>>>
>>> Now, _any_ library which fits would make me happy, as long as they agree
>>> to two points:
>>>
>>> - Either lightweight or with optional features. Else, it would only
>>> transfer bloat to freenet-ext.jar. For example: log2socket, config
>>> management and multiple logging instances;
>>> - Implementable in a few LoC. Specially, it shouldn't need specialized
>>> Formatter and Writer.
>>>
>>> Plus, it should be fast.
>>>
>>> From the quick research I made (yep, too many lists):
>>>
>>> - SLF4J already fails on point one: it is simply a wrapper;
>>> - The Java logging API fails on point two: specialized classes would
>>> have to be written to deal with log rotation, per-class filtering and
>>> formatting, plus a wrapper for Logger.{info,warning,...}() methods.
>>> Exactly the same as a custom logger, with one more dependency and using
>>> more LoC;
>>>
>> No dependancies, it's part of the JDK, isn't it?
>>
> More classes need to be loaded at startup. It's just me thinking too much.
>
>
>> However, if it's not a clearer/simpler API, it probably doesn't make much
>> sense.
>>
>> - Log4J seems to fail on point one - it only lacks a button that brings
>>> back the dead. It seems interesting, and I haven't dropped this yet.
>>>
>>> In either case (custom or external), log* would be banished. Forever.
>>>
>> I don't follow. You object to using a separate logs folder?
>>
> log* == log{MINOR,DEBUG}, not the logs folder.
> ______________________________**_________________
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.**org/cgi-bin/mailman/listinfo/**devl<https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20120322/5cfd749a/attachment.html>
