commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From benbenw <...@git.apache.org>
Subject [GitHub] commons-lang pull request #169: LANG-1248 FastDatePrinter Memory allocation ...
Date Wed, 06 Jul 2016 07:40:47 GMT
GitHub user benbenw opened a pull request:

    https://github.com/apache/commons-lang/pull/169

    LANG-1248 FastDatePrinter Memory allocation regression

    When the code was migrated from StringBuffer to Appendable in LANG-1152.
    We've lost the ability to modify the buffer (setCharAt) 
    The new implementation of appendFullDigits allocate a temporary char
    array to work around that limitation.
    This is a major source of memory allocation which is not present in
    version 3.4.
    Test case : 
    Single fastdateformat instance
    100000 format of long 
    pattern : yyyy-MM-dd'T'HH:mm:ss.SSSZ
    lang 3.4 : ~30 MB allocated
    lang 3.5-snapshot : ~40 MB allocated
    -> ~9.3 MB are coming from appendFullDigits called from
    PaddedNumberField
    
    This commit add a fast path for 1 to 4 digits which avoid the memory
    allocation from the temporary work array.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/benbenw/commons-lang LANG-1248

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/commons-lang/pull/169.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #169
    
----
commit d201ad32af1e71140539fbd7efe701f6b2e89ffe
Author: benoit <b.wiart@ubik-ingenierie.com>
Date:   2016-07-06T07:14:08Z

    LANG-1248 FastDatePrinter Memory allocation regression
    
    When the code was migrated from StringBuffer to Appendable in LANG-1152.
    We've lost the ability to modify the buffer (setCharAt) 
    The new implementation of appendFullDigits allocate a temporary char
    array to work around that limitation.
    This is a major source of memory allocation which is not present in
    version 3.4.
    Test case : 
    Single fastdateformat instance
    100000 format of long 
    pattern : yyyy-MM-dd'T'HH:mm:ss.SSSZ
    lang 3.4 : ~30 MB allocated
    lang 3.5-snapshot : ~40 MB allocated
    -> ~9.3 MB are coming from appendFullDigits called from
    PaddedNumberField
    
    This commit add a fast path for 1 to 4 digits which avoid the memory
    allocation from the temporary work array.

----


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message