[
https://issues.apache.org/jira/browse/HBASE-13448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14566230#comment-14566230
]
Lars Hofhansl commented on HBASE-13448:
---------------------------------------
I'd read 8.4s vs 8.5s that there was no statistically significant improvement
not that the new code is necessary slower (there was variance in the test runs
that was sometimes systemics across many runs).
Yes, the table was fully compacted. So what's best way to test this? When data
is sent back to the client, a percent or two saved should be insignificant
compared to the cost of creating the result object and shipping that to the
client.
My overall comment still stands: For 1 or 2% perf improvement it might not be
worth increasing the memory footprint of the data, which is already high.
Ideally a Cell (and especially KeyValue) is passed around just as a pointer,
the closest thing we have to that in Java is a handle of a byte[] + offset into
the array. Anything is overhead until we prove it is not :)
Yeah, let's fix that thingy in 0.98.
> New Cell implementation with cached component offsets/lengths
> -------------------------------------------------------------
>
> Key: HBASE-13448
> URL: https://issues.apache.org/jira/browse/HBASE-13448
> Project: HBase
> Issue Type: Sub-task
> Components: Scanners
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Fix For: 2.0.0
>
> Attachments: 13448-0.98.txt, HBASE-13448.patch, HBASE-13448_V2.patch,
> HBASE-13448_V3.patch, gc.png, hits.png
>
>
> This can be extension to KeyValue and can be instantiated and used in read
> path.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
