On Sat, Aug 28, 2021 at 3:16 PM Ron Grabowski
wrote:
> Follow-up to "Formatting the date is expensive. The process of actually
> formatting a value is reasonable". Is this still an issue from LOG4J2-930:
> %m %ex%n: 1,755,573 msg/sec%d %m %ex%n: 1,194,184 msg/sec
>
No, I believe that
Have you pushed that up somewhere? I would like to test it.
Is it possible to have direct encoders disabled by default unless something
else that indicates GC Free logging is desired is enabled? From what I can tell
the CPU overhead of GC Free logging makes it not worth it for most Java apps.
Hey everyone, we have a new release candidate for Log4j Kotlin API.
This is a vote to release Log4j Kotlin API 1.1.0. Please download,
validate, and cast your votes here.
[] +1, release the artifacts
[] -1, don't release because...
The vote will remain open for 72 hours (or more if required). All
Apologies, cancelling this release. The changelog wasn't updated yet,
and upon reviewing it, the version number proposed doesn't make sense.
I'll follow up shortly with a 1.1-rc1.
On Sat, Aug 28, 2021 at 2:34 PM Matt Sicker wrote:
>
> Hey everyone, we have a new release candidate for Log4j
Hey everyone, we have a new release candidate for Log4j Kotlin API.
This is a vote to release Log4j Kotlin API 1.0.1. Please download,
validate, and cast your votes here.
[] +1, release the artifacts
[] -1, don't release because...
The vote will remain open for 72 hours (or more if required). All
I don’t particularly want to optimize for the benchmarks, in most cases by
pre-generating the formatted dates we’d end up doing substantially more work
because we don’t log an event every millisecond/microsecond in practice.
I’ve pushed a relatively naive optimization which takes into account
May a ringbuffer cache be a viable solution?
Knowing the resolution (ticks, microseconds, milliseconds, seconds,..), a
key could be generated to lookup and return a previously created formatted
string from a ringbuffer or create it on the fly and store it for later.
During bursts of log events,
If you look at log4j-perf you will see both a TimeFormatBenchmark and a
ClocksBenchmark. The time
benchmark doesn’t include java.time’s formatter but I am pretty sure I added it
to find that it was still
slower than our formatters. However, the TimeFormat benchmark tests using
Follow-up to "Formatting the date is expensive. The process of actually
formatting a value is reasonable". Is this still an issue from LOG4J2-930:
%m %ex%n: 1,755,573 msg/sec%d %m %ex%n: 1,194,184 msg/sec
If so, isn't date rendering essentially a sequence we can generate ahead of
time similar
