Uploaded image for project: 'Johnzon'
  1. Johnzon
  2. JOHNZON-293

Potential high memory consumption in DateConverter

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Mapper
    • Labels:
      None

      Description

      DateConverter 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:

      1. Create a new SimpleDateFormat within the toString and fromString methods as method variable instead of a class field.
      2. 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):

      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
      

      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                elexx Alexander Falb
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 40m
                  40m