-
Enhancement
-
Resolution: Fixed
-
P4
-
None
-
b23
When printing number fields and and fractional fields, the DateTimeFormatters produced by java.time.format.DateTimeFormatterBuilder can produce a lot of allocations.
- Some are intrinsic to how java.time operates: Instants are converted to ZonedLocalDateTime before printing, along with a DateTimePrintContext. So at least 5 objects are allocated
- Then each number field is turned into a String before appending it to the buffer.
- For fractional fields, for example the sub-second part in a pattern like "HH:mm:ss.SSS", we always use a rather generic method involving BigDecimal.
In this enhancement I will deal with the second two inefficiencies. Integral numbers can be emitted directly to the buffer, and for NANO_OF_SECOND (the single most common "fraction") we can get exactly the same result with only int arithmetic and avoid the BigDecimal dance altogether. For some of the patterns tested this realizes a 80-85% reduction in allocation while speeding up the formatting by 1.7x.
- Some are intrinsic to how java.time operates: Instants are converted to ZonedLocalDateTime before printing, along with a DateTimePrintContext. So at least 5 objects are allocated
- Then each number field is turned into a String before appending it to the buffer.
- For fractional fields, for example the sub-second part in a pattern like "HH:mm:ss.SSS", we always use a rather generic method involving BigDecimal.
In this enhancement I will deal with the second two inefficiencies. Integral numbers can be emitted directly to the buffer, and for NANO_OF_SECOND (the single most common "fraction") we can get exactly the same result with only int arithmetic and avoid the BigDecimal dance altogether. For some of the patterns tested this realizes a 80-85% reduction in allocation while speeding up the formatting by 1.7x.
