Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id F18AA104C0 for ; Thu, 7 Nov 2013 19:39:17 +0000 (UTC) Received: (qmail 53676 invoked by uid 500); 7 Nov 2013 19:39:17 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 53645 invoked by uid 500); 7 Nov 2013 19:39:17 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 53636 invoked by uid 99); 7 Nov 2013 19:39:17 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Nov 2013 19:39:17 +0000 Date: Thu, 7 Nov 2013 19:39:17 +0000 (UTC) From: "Jean-Marc Spaggiari (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-9915) Severe performance bug: isSeeked() in EncodedScannerV2 is always false MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-9915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13816329#comment-13816329 ] Jean-Marc Spaggiari commented on HBASE-9915: -------------------------------------------- Have you compared the performances with and without? I have a fresh 0.94 perf test running, I can try to apply this and re-run to see the difference... > Severe performance bug: isSeeked() in EncodedScannerV2 is always false > ---------------------------------------------------------------------- > > Key: HBASE-9915 > URL: https://issues.apache.org/jira/browse/HBASE-9915 > Project: HBase > Issue Type: Bug > Reporter: Lars Hofhansl > Assignee: Lars Hofhansl > Fix For: 0.98.0, 0.96.1, 0.94.14 > > Attachments: 9915-0.94.txt, profile.png > > > While debugging why reseek is so slow I found that it is quite broken for encoded scanners. > The problem is this: > AbstractScannerV2.reseekTo(...) calls isSeeked() to check whether scanner was seeked or not. If it was it checks whether the KV we want to seek to is in the current block, if not it always consults the index blocks again. > isSeeked checks the blockBuffer member, which is not used by EncodedScannerV2 and thus always returns false, which in turns causes an index lookup for each reseek. -- This message was sent by Atlassian JIRA (v6.1#6144)