[
https://issues.apache.org/jira/browse/HBASE-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704194#action_12704194
]
stack commented on HBASE-1249:
------------------------------
@Holstad
Do you have profiling stats that show us getting gains we'll even be able to
notice?
.bq You have your KeyValue iterator, data length k, your columns asked for,
gets length l, and your deleteStructure, deletes length m.
I don't follow the above and can you expand more on your exposition on why
things will be faster? Looks like you've spent some time figuring it.
1. My sense is that the delete check is not costly, not in the scheme of things.
2. There is caching of lengths being done in many of those cases, right?
3. I was going to say that I don't think this expensive in the scheme of things
but just looked at PE profiling and see it taking 2% of CPU... this and
getRegion... and this is with the simple PE schema (one family).
-1 on duplicated code. Lets work on that. Especially when its complex code
like this.
You talked of 2x speedup. How'd you make out that?
> Rearchitecting of server, client, API, key format, etc for 0.20
> ---------------------------------------------------------------
>
> Key: HBASE-1249
> URL: https://issues.apache.org/jira/browse/HBASE-1249
> Project: Hadoop HBase
> Issue Type: Improvement
> Reporter: Jonathan Gray
> Priority: Blocker
> Fix For: 0.20.0
>
> Attachments: HBASE-1249-Example-v1.pdf, HBASE-1249-Example-v2.pdf,
> HBASE-1249-GetQuery-v1.pdf, HBASE-1249-GetQuery-v2.pdf,
> HBASE-1249-GetQuery-v3.pdf, HBASE-1249-GetQuery-v4.pdf,
> HBASE-1249-StoreFile-v1.pdf, HBASE-1249-StoreFile-v4.pdf
>
>
> To discuss all the new and potential issues coming out of the change in key
> format (HBASE-1234): zero-copy reads, client binary protocol, update of API
> (HBASE-880), server optimizations, etc...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
