No one is benchmarking JRE's JIT. If you look closer, there are figures
with the average runtime without JIT, exactly to avoid overspecialization.
With JIT, there is a reduction of 0.02% in runtime. Without JIT, this
becomes 0.06%. Negligible to all but the few people who do everything in
assembly.
I am more worried with possible lock contention.
On 22-03-2012 23:30, Zlatin Balevsky wrote:
> 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
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
