Lazy evaluation is trivial.
Log.info("{1} did {2}",
new Object(){ public String toString() { return ITEM_1; } },
new Object(){ public String toString() { return ITEM_2; } }
);
Garbage collection with short-lived objects costs next to nothing.
On 22/03/12 21:15, Zlatin Balevsky wrote:
> 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
> <mailto: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 <mailto:Devl at freenetproject.org>
> https://emu.freenetproject.__org/cgi-bin/mailman/listinfo/__devl
> <https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl>
>
>
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
--
GPG: 4096R/5FBBDBCE
https://github.com/infinity0
https://bitbucket.org/infinity0
https://launchpad.net/~infinity0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20120322/c9893157/attachment.pgp>
