I've implemented the changes in the way you and Piotr requested:
https://github.com/apache/logging-log4j2/pull/3121 That is, implemented
minute-precision caching and use `DateTimeFormatter` for sub-minute
precision parts (e.g., `ss.SSS`). *Would you mind reviewing the changes,
please?*
(Change imp
Volkan,
Piotr’s proposal sounds reasonable to me. Does it to you?
Ralph
> On Oct 15, 2024, at 4:36 AM, Piotr P. Karwasz wrote:
>
> Hi Volkan,
>
> On Mon, 14 Oct 2024 at 21:30, Volkan Yazıcı wrote:
>> Hence, I propose switching all layouts to use `DateTimeFormatter`, unless
>> the `log4j.time
Hi Volkan,
On Mon, 14 Oct 2024 at 21:30, Volkan Yazıcı wrote:
> Hence, I propose switching all layouts to use `DateTimeFormatter`, unless
> the `log4j.time.legacyFormatterEnabled` property is provided. Objections?
Can you upgrade `FixedDateFormat` to use DTF as date formatter and use
it whenever
That's quite a difference! Why would we make things deliberately slower?
Gary
On Mon, Oct 14, 2024, 4:57 PM Ralph Goers
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 Ya
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{-MM-dd'
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ı wrote:
>
> Some results using Java 17:
>
>
> *-MM-dd'T'HH:mm:ss.SSS*DateTimeFormatter 2.844 ± 0.310 ops/ms
> FastDateFormat
Some results using Java 17:
*-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
FastDateFormat10.862 ± 1.915 ops/ms
FixedDateFormat 39.
I think it would make sense to switch to the standard Java one. The custom
classes mostly predated Java 8, and I’ve seen enough test failures whenever
daylight saving time starts or ends to know that they’re buggy.
> On Oct 14, 2024, at 14:30, Volkan Yazıcı wrote:
>
> *Abstract:* Log4j contain
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.
