DateTimeFormatter.format() uses exceptions for flow control
Stephen Colebourne
scolebourne at joda.org
Sun Oct 9 20:52:38 UTC 2016
This looks like it should be a worthwhile improvement.
Stephen
On 9 October 2016 at 16:24, Clément MATHIEU <clement at unportant.info> wrote:
> Hi !
>
> I noticed that DateTimePrintContext.getValue() relies on exceptions to
> handle optionality. Using exceptions for flow control seems both
> unexpected and very costly, ie. I discovered the issue
> when LocaleDate.format(BASIC_ISO_DATE) showed up as a heavy hitter in
> my application.
>
> Formatting a LocateDate as a "yyyyMMdd" string should take ~0.1μs but
> currently takes from ~2.5μs, stack depth = 0, to ~10μs, stack depth =
> 128 when an optional parser is defined but the optional field is not
> supported. This seems unfortunate when exceptions can easily be avoided
> by testing if the field is supported before trying to get its value.
>
> Webrev:
>
> http://cdn.unportant.info/openjdk/dtf_exceptions/webrev.00/
>
> JMH benchmarks:
>
> https://gist.github.com/cykl/020e1527546a1ba44b4bb3af6dc0484c
>
>
> What do you think ?
>
>
> Note: Many tests within java.time are currently broken because of
> TestNG upgrade, see https://bugs.openjdk.java.net/browse/JDK-8152944.
> Would it help if I spend some time adding the missing L suffixes ?
>
> Regards,
>
> Clément MATHIEU
More information about the core-libs-dev
mailing list