You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Chetan Mehrotra (JIRA)" <ji...@apache.org> on 2016/06/02 11:31:59 UTC

[jira] [Updated] (OAK-4421) Optimize Revison fromString and toString implementation

     [ https://issues.apache.org/jira/browse/OAK-4421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chetan Mehrotra updated OAK-4421:
---------------------------------
    Attachment: OAK-4421-v1.patch

[initial patch|^OAK-4421-v1.patch] for the same

# Revision.fromString - Folded in the parsing of hex to Long as default implementation in Java is too generic (accounts for multi byte string etc) and create quite a few objects
# Revision.toString - Folded in the logic to conver long to hex 
# RevisionVector - Provided a suitable default for the StringBuilder such that it does not need to be expanded as profiling shows that some time was being spent in extending the buffer while generating string

[~mreutegg] [~tmueller] Can you review the approach and provide feedback.

> Optimize Revison fromString and toString implementation
> -------------------------------------------------------
>
>                 Key: OAK-4421
>                 URL: https://issues.apache.org/jira/browse/OAK-4421
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: documentmk
>            Reporter: Chetan Mehrotra
>            Assignee: Chetan Mehrotra
>             Fix For: 1.6
>
>         Attachments: OAK-4421-v1.patch
>
>
> Current implementation of Revision {{fromString}} and {{toString}} make use of std JDK API to perform string manipulation. While running some performance test it was seen that these 2 methods are called quite frequently and that adds up to some decent times. Further they also generate quite a bit of short lived objects.
> It would be worthwhile to perform a micro benchmark of these method and optimize them further such that they perform better and also generate less garbage. The micro optimized code would be bit more complex but if performance numbers are better we can look into changing the current implementation



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)