-
Bug
-
Resolution: Unresolved
-
P4
-
None
-
11.0.1
The current implementation of OffsetDateTime.parse() (and potentially other parse methods) is very slow due to excessive internal allocations caused for example by java.time.format.Parsed.copy() and other usages of the formatter's internal HashMap, see attached screenshots of a JMC profiling session.
A benchmark shows that a very simple hand-written parser (taken from jOOQ, implementation can be seen in attached OffsetDateTimeParsingBenchmark.java file) can easily outperform the official parser by a factor of 10x:
Benchmark Mode Cnt Score Error Units
OffsetDateTimeParsingBenchmark.testAlternative thrpt 14 8760053.163 ± 1063735.801 ops/s
OffsetDateTimeParsingBenchmark.testNative thrpt 14 641244.464 ± 28909.694 ops/s
The hand-written parser needs to take into account a few specialties of certain JDBC driver, so a hand-written parser to parse ISO timestamps only would likely be even faster.
While being able to write custom formatters using the java.time.format.DateTimeFormatter DSL is definitely useful, the standard ISO formatters and parsers should be implemented using a more specialised implementations that does not require any internal HashMaps for storing generic intermediary values, nor BigDecimal allocations for managing fractions.
A benchmark shows that a very simple hand-written parser (taken from jOOQ, implementation can be seen in attached OffsetDateTimeParsingBenchmark.java file) can easily outperform the official parser by a factor of 10x:
Benchmark Mode Cnt Score Error Units
OffsetDateTimeParsingBenchmark.testAlternative thrpt 14 8760053.163 ± 1063735.801 ops/s
OffsetDateTimeParsingBenchmark.testNative thrpt 14 641244.464 ± 28909.694 ops/s
The hand-written parser needs to take into account a few specialties of certain JDBC driver, so a hand-written parser to parse ISO timestamps only would likely be even faster.
While being able to write custom formatters using the java.time.format.DateTimeFormatter DSL is definitely useful, the standard ISO formatters and parsers should be implemented using a more specialised implementations that does not require any internal HashMaps for storing generic intermediary values, nor BigDecimal allocations for managing fractions.