The example you provide is fast because it does not do any object
allocation. Please don't take my word for it - download (or better
yet, build one yourself) a "fastdebug" build from openjdk.org and look
at the opto-assembly that gets generated when you pass the
"-XX:+PrintOptoAssembly" switch.
Benchmarking JIT's is a fascinating topic but beyond the scope of this
list. Furthermore, anything I say applies only to the Hotspot JVM.
On Thu, Mar 22, 2012 at 8:18 PM, Marco Schulze
<marco.c.schulze at gmail.com> wrote:
>
> 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" <infinity0 at gmx.com> 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" <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
>>
>>
>> _______________________________________________
>> Devl mailing list
>> Devl at freenetproject.org
>> 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
>
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
