I already have all but log rotation and async ready, and haven't yet found a
single benchmark supporting the use of a branch as the performance holy grail.
For example (outputting to /dev/null):
public static void main (String[] args) {
for (int i = 0; i< 1000000; i++) {
Log.fatal (Log.class, Log.class, "akd\n\n", i, '\n', out, ' ');
Log.trace (Log.class, Log.class, "akd\n\n", i, '\n', out, ' ');
}
}
Every call means, minimally, varargs boxing, another call (since fatal() and
trace() are simple convenience methods) and an isLoggable() check composed by a
ConcurrentHashMap lookup against the class name and (possibly) a synchronized
read on the global threshold. trace() is filtered but fatal() is not.
This snipped ran in an average 6.482 seconds. If the call to trace() is
commented out (thus removing the filtering overhead), the average falls to
6.366 seconds. Disabling JIT, the figures became 1:37.952 and 1:35.880,
respectively. Over a million calls, checking costs only a few milliseconds.
To be sure, this is a fairly simple example: it all runs on a single thread,
the hash table is empty and the pressure on the GC is low. Still, differences
are very small. Plus, there's no overhead due to a dedicated logging thread.
On 22-03-2012 18:59, Zlatin Balevsky wrote:
Double-digit millisecond pauses are not nothing. They may be acceptable right
now but unless you can offer a drastically cleaner syntax Fred should stick
with predicates as they are handled much better by the hotspot jit.
On Mar 22, 2012 5:36 PM, "Ximin Luo"<[email protected]> wrote:
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"<[email protected]
<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
https://emu.freenetproject.__org/cgi-bin/mailman/listinfo/__devl
<https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl>
_______________________________________________
Devl mailing list
[email protected]
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
--
GPG: 4096R/5FBBDBCE
https://github.com/infinity0
https://bitbucket.org/infinity0
https://launchpad.net/~infinity0
_______________________________________________
Devl mailing list
[email protected]
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
_______________________________________________
Devl mailing list
[email protected]
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
_______________________________________________
Devl mailing list
[email protected]
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
