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 <ralph.go...@dslextreme.com> 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ı <vol...@yazi.ci.INVALID> > 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. > >
