Aren’t lambdas garbage free? At least if you don’t close over any state that is.
On Thu, Oct 25, 2018 at 17:07, Remko Popma <[email protected]> wrote: > A dirty alternative is to check with instanceof and cast to > IndexedStringMap and use indexed access. But BiConsumer or TriConsumer are > a lot cleaner. > > (Shameless plug) Every java main() method deserves http://picocli.info > > > On Oct 25, 2018, at 20:55, Volkan Yazıcı <[email protected]> > wrote: > > > > It is not really that easy in my case -- there are variables reached > > outside of the scope. But ok, I will see what I can do about it. I > > thought there might exist a utility class or sth like that to let me > > access it like a List/Array. > > > > What about the ContextStack? > > > >> On Thu, Oct 25, 2018 at 10:19 AM Remko Popma <[email protected]> > wrote: > >> > >> You can keep a pre-allocated BiConsumer (or multiple ThreadLocal ones) > to > >> avoid allocating a new consumer for each event. (I think that’s what we > do > >> in Log4j.) > >> > >> Remko. > >> > >> (Shameless plug) Every java main() method deserves http://picocli.info > >> > >>> On Oct 25, 2018, at 15:50, Volkan Yazıcı <[email protected]> > >> wrote: > >>> > >>> One thing I am still struggling is how to iterate over ContextData and > >>> ContextStack without any garbage. > >>> ContextData#forEach() necessitates instantiation of a new > >>> BiConsumer<String, Object>. > >>> And likewise, ContextStack necessitates instantiation of a new Iterator > >> for > >>> traversal. > >>> Am I missing something? Is there any other way to traverse these > >>> collections without generating garbage? > >>> > >>>> On Tue, Oct 23, 2018 at 2:28 AM Remko Popma <[email protected]> > >> wrote: > >>>> > >>>> Looks very nice! > >>>> > >>>> The non garbage-free implementation is in the toSerializable(LogEvent) > >>>> method. As you point out, this often ends in a call to > >>>> StringBuilder.toString(). > >>>> > >>>> The garbage-free implementation is in the encode(LogEvent, > >>>> ByteBufferDestination) method. This reuses a ThreadLocal > StringBuilder. > >>>> > >>>> Be aware of edge cases like occasional very large messages that result > >> in > >>>> the reusable StringBuilder taking up a lot of memory and never > releasing > >>>> it. (We trim if some configurable max size is exceeded.) > >>>> You get some of this for free by extending AbstractStringLayout. > >>>> > >>>> I took a brief look at the BENCHMARK.txt file but didn’t have time to > >> look > >>>> in detail. A graph comparison would be very cool! > >>>> > >>>> Good luck, keep us posted! > >>>> > >>>> (Shameless plug) Every java main() method deserves > http://picocli.info > >>>> > >>>>> On Oct 23, 2018, at 6:40, Volkan Yazıcı <[email protected]> > >> wrote: > >>>>> > >>>>> Hello, > >>>>> > >>>>> I am working on the next release of log4j2-logstash-layout > >>>>> <https://github.com/vy/log4j2-logstash-layout/tree/json-generator>, > >>>> which > >>>>> is an alternative to the default JsonLayout and allows custom JSON > >>>> schemas. > >>>>> There I achieved to get up to 5x speed up compared to JsonLayout[1] > >> and I > >>>>> want to stretch this further by reducing the GC load. Though it is > >> really > >>>>> difficult given Layout interface (practically) requires an output of > >> type > >>>>> String. I examined the internals of other gc-free layouts, e.g., > >> Pattern, > >>>>> Gelf, etc. Though each ends up making a call to > >> StringBuilder#toString(), > >>>>> which is not gc-free, to the best of my knowledge. Would anyone mind > >>>>> shedding some light onto the issue, please? > >>>>> > >>>>> Best. > >>>>> > >>>>> [1] Please feel free to check JMH benchmarks > >>>>> < > >>>> > >> > https://github.com/vy/log4j2-logstash-layout/blob/json-generator/layout/src/test/perf/com/vlkan/log4j2/logstash/layout/LogstashLayoutBenchmarkState.java > >>>>> > >>>>> and their results > >>>>> < > >>>> > >> > https://github.com/vy/log4j2-logstash-layout/blob/json-generator/BENCHMARK.txt > >>>>> . > >>>>> Maybe there I am misconfiguring JsonLayout to cause it under-perform. > >>>> > >> > -- Matt Sicker <[email protected]>
