DateTimeFormatter.format() uses exceptions for flow control
David Holmes
david.holmes at oracle.com
Sun Oct 9 20:47:39 UTC 2016
Hi Clement,
Please note that patches can only be accepted if they are sent through,
or hosted upon OpenJDK infrastructure. If the patch is small enough can
you send it inline in the email (attachments are often stripped)
otherwise you will need to find an OpenJDK Author who can host the patch
for you on cr.openjdk.java.net
Thanks,
David
On 10/10/2016 1:24 AM, Clément MATHIEU 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