Please take into account that date & time formatting constitutes a small
part of the entire encoding need of a layout. That is, if we switch from
`FixedDateFormat` to `DateTimeFormatter`, it does *NOT* mean that the
overall slowdown will be 20 fold. Below are some figures:
*Pattern*
%d{yyyy-MM-dd'T'HH:mm:ss.SSS} [%t] %p %-40.40c{1.} %notEmpty{%x }- %m%n
*Using full log events (incl. exception, MDC & NDC)*
FastDateFormat 0.039 ± 0.001 ops/ms
DateTimeFormatter 0.039 ± 0.001 ops/ms
FixedFormat 0.040 ± 0.001 ops/ms
Above figures show that when an exception rendering is involved, date &
time formatting efficiency becomes irrelevant.
*Using lite log events*
DateTimeFormatter 1.888 ± 0.106 ops/ms
FastDateFormat 2.567 ± 0.032 ops/ms
FixedDateFormat 4.793 ± 0.019 ops/ms
Above figures show that for message-only (i.e., lite) log events, there is
a ~37% performance degradation for those who want to encode more than ~1900
events per second per core. Such users can still fallback to legacy
formatters using the `log4j.time.legacyFormatterEnabled` property.
On Mon, Oct 14, 2024 at 10:57 PM Ralph Goers <[email protected]>
wrote:
> Wow. I didn’t expect them to be that much faster. That makes me very
> reluctant to be ok with switching.
>
> Ralph
>
>
>
> > On Oct 14, 2024, at 1:51 PM, Volkan Yazıcı <[email protected]>
> wrote:
> >
> > Some results using Java 17:
> >
> >
> > *yyyy-MM-dd'T'HH:mm:ss.SSS*DateTimeFormatter 2.844 ± 0.310 ops/ms
> > FastDateFormat 6.847 ± 1.302 ops/ms
> > FixedDateFormat 39.497 ± 6.423 ops/ms
> >
> > *HH:mm:ss.SSS*
> > DateTimeFormatter 3.881 ± 0.447 ops/ms
> > FastDateFormat 10.862 ± 1.915 ops/ms
> > FixedDateFormat 39.618 ± 9.318 ops/ms
> >
> >
> > I used distinct instants within the same day to avoid cache misses in
> > `FixedDateFormat`'s cache on the `yyyy-MM-dd` part, which is updated
> daily
> > at midnight. That is why `FixedDF` figures are more or less the same for
> > both patterns.
> >
> > On Mon, Oct 14, 2024 at 9:48 PM Ralph Goers <[email protected]>
> > wrote:
> >
> >> Before I can weigh in one way or another I would need to know what the
> >> performance difference is between DateTimeFormatter and the Fixed and
> Fast
> >> classes, at least where they are working properly. Any such test should
> >> include the caching otherwise you would be comparing worst case
> performance.
> >>
> >> Ralph
> >>
> >>> On Oct 14, 2024, at 12:30 PM, Volkan Yazıcı <[email protected]>
> >> wrote:
> >>>
> >>> *Abstract:* Log4j contains two custom date & time formatting classes.
> All
> >>> our competitors (Logback
> >>> <
> >>
> https://github.com/qos-ch/logback/blob/master/logback-core/src/main/java/ch/qos/logback/core/util/CachingDateFormatter.java
> >>> ,
> >>> Tinylog
> >>> <
> >>
> https://github.com/tinylog-org/tinylog/blob/7590ad150b1523691ae6f26ae24a291b81d804c9/tinylog-api/src/main/java/org/tinylog/runtime/PreciseTimestampFormatter.java
> >>> ,
> >>> etc.) use Java's `DateTimeFormatter` and I know of no user complaints
> >> about
> >>> their performance issues. Shall we switch to `DateTimeFormatter` as the
> >>> default in the next minor release and make the custom implementations
> >>> opt-in?
> >>>
> >>> Log4j ships two custom date & time formatting classes:
> >>>
> >>> - `FixedDateFormat`
> >>> - Supports a hardcoded list of formats
> >>> - Bug: Conflates `n` directive with `S`
> >>> - Bug: It cannot calculate DST correctly for all time zones
> >>> <https://github.com/apache/logging-log4j2/issues/2943>
> >>> - `FastDateFormat`
> >>> - Copied from Commons Lang in 2015
> >>>
> >>> I recently ran a test comparing the output of these with
> >>> `DateTimeFormatter` – the difference is *big*! I can spend months
> fixing
> >>> these issues, but... Do we really need them?
> >>>
> >>> 1. No other competitors have such an optimization (both Logback
> >>> <
> >>
> https://github.com/qos-ch/logback/blob/master/logback-core/src/main/java/ch/qos/logback/core/util/CachingDateFormatter.java
> >>>
> >>> and Tinylog
> >>> <
> >>
> https://github.com/tinylog-org/tinylog/blob/7590ad150b1523691ae6f26ae24a291b81d804c9/tinylog-api/src/main/java/org/tinylog/runtime/PreciseTimestampFormatter.java
> >>>
> >>> use
> >>> `DateTimeFormatter`)
> >>> 2. Date & time formatting is very fragile (DST is more voodoo than
> >>> science)
> >>> 3. If date & time formatting during logging is found to be the
> >>> bottleneck of an application, shouldn't they instead encode it
> >> differently,
> >>> e.g., encoding epoch numbers?
> >>> 4. `DateTimeFormatter` performance will only get better over time
> >>>
> >>> Hence, I propose switching all layouts to use `DateTimeFormatter`,
> unless
> >>> the `log4j.time.legacyFormatterEnabled` property is provided.
> Objections?
> >>>
> >>> Note that the caching optimization we have for the last formatted
> >> timestamp
> >>> will stay untouched.
> >>
> >>
>
>
