[
https://issues.apache.org/jira/browse/HBASE-7279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510293#comment-13510293
]
Matt Corgan commented on HBASE-7279:
------------------------------------
{quote}(we could envision an "ArrayPtr" object, which holds a reference to an
array, offset, and length, but then that would another object to create){quote}
Lars - I submitted a ByteRange class when the Cell interface was committed
which is exactly the ArrayPtr. I use it extensively in the PrefixTree module
to make the code more robust and readable, but I always pool and reuse them in
the hot code paths. It makes byte[]'s as easy to use as Strings for
comparisons, copying, substrings, collections, sorting, deduping, etc. Sounds
like not the right choice for this situation, but thought I'd point it out so
you know about it.
> Avoid copying the rowkey in RegionScanner, StoreScanner, and ScanQueryMatcher
> -----------------------------------------------------------------------------
>
> Key: HBASE-7279
> URL: https://issues.apache.org/jira/browse/HBASE-7279
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Fix For: 0.96.0, 0.94.4
>
> Attachments: 7279-0.94.txt
>
>
> Did some profiling again.
> I we can gain some performance [1] when passing buffer, rowoffset, and
> rowlength instead of making a copy of the row key.
> That way we can also remove the row key caching (and this patch also removes
> the timestamps caching). Considering the sheer number in which we create KVs,
> every byte save is good.
> [1] (15-20% when data is in the block cache we setup a Filter such that only
> a single row is returned to the client).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
