Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-dev@hadoop.apache.org
Message-ID: <71165324.1241033250419.JavaMail.jira@brutus>
Date: Wed, 29 Apr 2009 12:27:30 -0700 (PDT)
From: "Erik Holstad (JIRA)" <jira@apache.org>
To: hbase-dev@hadoop.apache.org
Subject: [jira] Commented: (HBASE-1249) Rearchitecting of server, client,
 API, key format, etc for 0.20
In-Reply-To: <728871099.1236620030451.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HBASE-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704272#action_12704272 ] 

Erik Holstad commented on HBASE-1249:
-------------------------------------

@Stack

{quote}1. My sense is that the delete check is not costly, not in the
scheme of things.{quote}
I would say that it is costly in cases where you have many deletes.  I
also see no downside or big areas where the new design would perform any
worse.  We also need to think about memory allocation.

{quote}2. There is caching of lengths being done in many of those cases,
right?{quote}
I'm not sure exactly what you mean, but yes there may be.  But without it
being clear, it seems we would want to ensure in this very important (for
performance) code path is optimally reusing them.

One of the problems with java is that you can't return multiple things at
the same time in an easy way.  For me trying to make the server
implementation faster I'd rather have duplication of code than make it
slower.

I totally agree that we should try to keep duplication to a minimum, but I
rather focus on speed first and then work in minimizing the code base,
might be the wrong approach. When it comes to the part of duplicating
complex code I totally agree, this makes it more prone to errors and
should definitely be avoided when possible.

The code that I duplicate is mostly the compare code for 2 KeyValues, so
it is pretty straightforward, not like the more complex merge codes which

> 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.