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. >>>> >>
