lol, OK. I am just annoyed with everyone that keeps arguing "we need to implement our own generic X framework because of minor issue Y whose importance I am over-inflating, even though countless other projects with similar requirements get around these adequately".
To anyone doing refactoring work: ignore them. On 23/03/12 07:58, David ‘Bombe’ Roden wrote: > Yes, kids, both your penisses are incredibly long. Now shut up and let the > grown-ups do some refactoring. > > > Greetings, > > David > > On 23.03.2012, at 04:47, Ximin Luo wrote: > >> LOL, are you kidding me? >> >> Please point to the exact lines of code that results in "double-digit >> millisecond pauses"? >> >> Talk is cheap, show us some numbers. >> >> BTW, the "example" I gave is not real code, and contains no variable >> declarations, so your challenge makes no sense. Since you apparently didn't >> understand my implicit argument, here it is in more detail: a typical method >> that computes something simply for the purpose of logging it somewhere, >> usually >> only allocates local variables that are not stored anywhere in the long term. >> Escape analysis can turn these into stack allocations, saving GC overhead. >> (If >> they do use more long-term variables, they will need to be stored on the >> heap, >> but then GC doesn't need to clean these up anyway.) >> >> Why are you even looking at blog entries? Escape analysis has been around for >> years. http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/357d4e2eb4dd >> >> On 23/03/12 02:06, Zlatin Balevsky wrote: >>> My claim is based on day-to-day observations of hundreds of JVMs under >>> various >>> load scenarios. >>> >>> Your claim that modern JVMs "do escape analysis" is worthless as it shows >>> that >>> you have merely read some blog posts, and even those you've read only >>> partially. Please point to the exact lines of code in hotspot or any other >>> modern jvm that will optimize the specific lazy evaluation example you >>> presented, together with the opto-assembly that their JITs produce. Failing >>> that, take your attitude elsewhere. >>> >>> On Thu, Mar 22, 2012 at 8:49 PM, Ximin Luo <infini...@gmx.com >>> <mailto:infini...@gmx.com>> wrote: >>> >>> The "drastically cleaner syntax" is a red herring. Most of the time when >>> you >>> are doing a complex calculation, you are not going to put it on one line >>> anyway. In such cases, the function you are using to do the calculation >>> might >>> as well be the toString() method of some object. >>> >>> Your claim of "double-digit millisecond" pauses is worthless without some >>> benchmarking and actual numbers. Modern JVMs do escape analysis to avoid >>> heap >>> allocation and this helps especially for transient computations like in >>> logging. >>> >>> On 22/03/12 21: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" <infini...@gmx.com >>> <mailto:infini...@gmx.com> >>>> <mailto:infini...@gmx.com <mailto:infini...@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.schu...@gmail.com >>> <mailto:marco.c.schu...@gmail.com> >>>> <mailto:marco.c.schu...@gmail.com <mailto:marco.c.schu...@gmail.com>> >>>>> <mailto:marco.c.schu...@gmail.com >>> <mailto:marco.c.schu...@gmail.com> <mailto:marco.c.schu...@gmail.com >>> <mailto:marco.c.schu...@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@freenetproject.org <mailto:Devl@freenetproject.org> >>> <mailto:Devl@freenetproject.org <mailto:Devl@freenetproject.org>> >>>> <mailto:Devl@freenetproject.org <mailto:Devl@freenetproject.org> >>> <mailto:Devl@freenetproject.org <mailto:Devl@freenetproject.org>>> >>>>> https://emu.freenetproject.__org/cgi-bin/mailman/listinfo/__devl >>>>> <https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Devl mailing list >>>>> Devl@freenetproject.org <mailto:Devl@freenetproject.org> >>> <mailto:Devl@freenetproject.org <mailto:Devl@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 <https://launchpad.net/%7Einfinity0> >>>> >>>> >>>> _______________________________________________ >>>> Devl mailing list >>>> Devl@freenetproject.org <mailto:Devl@freenetproject.org> >>> <mailto:Devl@freenetproject.org <mailto:Devl@freenetproject.org>> >>>> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >>>> >>>> >>>> >>>> _______________________________________________ >>>> Devl mailing list >>>> Devl@freenetproject.org <mailto:Devl@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 <https://launchpad.net/%7Einfinity0> >>> >>> >>> _______________________________________________ >>> Devl mailing list >>> Devl@freenetproject.org <mailto:Devl@freenetproject.org> >>> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >>> >>> >>> >>> >>> _______________________________________________ >>> Devl mailing list >>> Devl@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@freenetproject.org >> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > _______________________________________________ > Devl mailing list > Devl@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
