[jira] [Comment Edited] (OAK-2626) Optimize binary comparison for merge during upgrade

["Julian Sedding (JIRA)" <ji...@apache.org>]

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

Julian Sedding edited comment on OAK-2626 at 5/18/15 9:58 AM:
--------------------------------------------------------------

[~chetanm] The idea here is indeed to avoid FileSystem access. In {{FileDataStore#getRecordIfStored()}} a call to {{File.exists()}} is done. In the upgrade scenario that turned out to take significant time on my Mac Book Pro with SSD. The logic in this patch bypasses FS access and reduces it to a string operation. I intended to make any reliance on implementation details optional. So the logic should fall back to public APIs if the optimization fails.

With the patch from OAK-2627 applied, the {{equals()}} method does probably not need to be overwritten by this patch.

This is especially interesting when re-running an upgrade with few changes to the source content, i.e. an incremental upgrade (which requires some of my other patches).


was (Author: jsedding):
[~chetanm] The idea here is indeed to avoid FileSystem access. In {{FileDataStore#getRecordIfStored()}} a call to {{File.exists()}} is done. In the upgrade scenario that turned out to take significant time on my Mac Book Pro with SSD. The logic in this patch bypasses FS access and reduces it to a string operation. I intended to make any reliance on implementation details optional. So the logic should fall back to public APIs if the optimization fails.

This is especially interesting when re-running an upgrade with few changes to the source content, i.e. an incremental upgrade (which requires some of my other patches).

> Optimize binary comparison for merge during upgrade 
> ----------------------------------------------------
>
>                 Key: OAK-2626
>                 URL: https://issues.apache.org/jira/browse/OAK-2626
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: upgrade
>    Affects Versions: 1.1.7
>            Reporter: Julian Sedding
>            Priority: Minor
>         Attachments: OAK-2626.patch, incremental-upgrade-no-changes.png
>
>
> In OAK-2619 I propose to support repeated upgrades into the same NodeStore.
> This issue does not optimizate the first run, but any subsequent run benefits from the proposed changes.
> One use-case for this feature is to import all content several days before the upgrade and then copy only the delta on the day of the upgrade.
> Assuming that both the source and target repositories use the same FileDataStore, binaries could be efficiently compared by their references.



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