This looks like it should be a worthwhile improvement. Stephen
On 9 October 2016 at 16:24, Clément MATHIEU <clem...@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
