[jira] [Commented] (JOHNZON-293) Potential high memory consumption in DateConverter

["Mark Struberg (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JOHNZON-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17271615#comment-17271615 ] 

Mark Struberg commented on JOHNZON-293:
---------------------------------------

[~elexx] did you find some time to dig into this? txs!

> Potential high memory consumption in DateConverter
> --------------------------------------------------
>
>                 Key: JOHNZON-293
>                 URL: https://issues.apache.org/jira/browse/JOHNZON-293
>             Project: Johnzon
>          Issue Type: Bug
>          Components: Mapper
>            Reporter: Alexander Falb
>            Priority: Major
>          Time Spent: 40m
>  Remaining Estimate: 0h
>
> [DateConverter|https://github.com/apache/johnzon/blob/master/johnzon-mapper/src/main/java/org/apache/johnzon/mapper/converter/DateConverter.java] creates a new SimpleDateFormat for every instance for every thread the instance is used on and never cleans them up. This may cause a high memory usage, if lots of those converters are created instead of reused. 
>  
> Two approaches to get rid of them are on my mind:
>  # Create a new SimpleDateFormat within the toString and fromString methods as method variable instead of a class field.
>  # Use java.time.DateTimeFormatter as class field, because it is immutable and thread-safe, and do some object conversion from java.util.Date to/from java.time.ZonedDateTime.
>  
> I did some JMH performance tests for both (full project can be found here [https://github.com/elexx/dateconverter-benchmark]):
> {noformat}
> Benchmark                                         Mode  Cnt     Score     Error  Units
> JavaTimeDateFormatterBenchmark.formatNewFormat    avgt    5   828,623 ±   8,836  ns/op
> JavaTimeDateFormatterBenchmark.formatReuseFormat  avgt    5   496,916 ±   5,150  ns/op
> JavaTimeDateFormatterBenchmark.parseNewFormat     avgt    5  1430,276 ±  11,084  ns/op
> JavaTimeDateFormatterBenchmark.parseReuseFormat   avgt    5   990,648 ± 280,983  ns/op
> SimpleDateFormatterBenchmark.formatNewFormat      avgt    5  1308,144 ±  13,993  ns/op
> SimpleDateFormatterBenchmark.formatReuseFormat    avgt    5   392,236 ±   3,219  ns/op
> SimpleDateFormatterBenchmark.parseNewFormat       avgt    5  1848,772 ±  19,412  ns/op
> SimpleDateFormatterBenchmark.parseReuseFormat     avgt    5  1121,955 ±  12,417  ns/op
> {noformat}
> In this quick test it looks like creating a new SimpleDateFormatter in each method is quite slow (1308ns/op + 1848ns/op).
> Reusing the SimpleDateFormatter is faster (392ns/op + 1121ns/op), but no option because it is not thread-safe.
> Reusing the Java8-DateTimeFormatter is equivalent (496ns/op + 990ns/op) to Reusing SimpleDateFormatter (parsing is faster, formatting is slower, avg is about the same)
> And just for completeness: Creating a Java8-DateTimeFormatter, which is nonsense, because it is immutable and thread-safe.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)