[jira] [Comment Edited] (OAK-3893) SegmentWriter records cache could use thinner keys

["Alex Parvulescu (JIRA)" <ji...@apache.org>]

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

Alex Parvulescu edited comment on OAK-3893 at 2/23/16 2:34 PM:
---------------------------------------------------------------

proposed patch.

even if we refactor the cache itself (which imho is a different topic), this patch still stands on the idea that using the template objects as keys is way too much overhead, and hashing them is beneficial.

[edit] too bad {{LazyValue}} from oak-core is not public, I ended up using a similar thing from Guava in the patch.


was (Author: alex.parvulescu):
proposed patch.

even if we refactor the cache itself (which imho is a different topic), this patch still stands on the idea that using the template objects as keys is way too much overhead, and hashing them is beneficial.

> SegmentWriter records cache could use thinner keys
> --------------------------------------------------
>
>                 Key: OAK-3893
>                 URL: https://issues.apache.org/jira/browse/OAK-3893
>             Project: Jackrabbit Oak
>          Issue Type: Technical task
>          Components: segmentmk
>            Reporter: Alex Parvulescu
>            Assignee: Alex Parvulescu
>            Priority: Minor
>         Attachments: OAK-3893.patch
>
>
> The SegmentWriter keeps a records deduplication cache ('records' map) that maintains 2 types of mappings:
> * template -> recordid
> * strings -> recordid
> For the first one (template-> recordid) we can come up with a thinner representation of a template (a hash function that is fast and not very collision prone) so we don't have to keep a reference to each template object.
> Same applies for second one, similar to what is happening in the StringsCache now, we could keep the string value up to a certain size and beyond that, hash it and use that for the deduplication map.



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