Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Tue, 2 Sep 2014 18:16:21 +0000 (UTC)
From: "Josh Elser (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12736103.1408728235000.10798.1409681781942@Atlassian.JIRA>
In-Reply-To: <JIRA.12736103.1408728235000@Atlassian.JIRA>
References: <JIRA.12736103.1408728235000@Atlassian.JIRA>
 <JIRA.12736103.1408728235177@arcas>
Subject: [jira] [Commented] (ACCUMULO-3079) improve system iterator
 performance by collapsing call stack
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/ACCUMULO-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14118457#comment-14118457 ] 

Josh Elser commented on ACCUMULO-3079:
--------------------------------------

I just stumbled on trying to figure out exactly what the SynchronizedIterator does (to document it) and noticed that you also made changes here to try to alleviate the extra iterator in the stack. I'm wondering if it makes sense to keep that synchronized filter in the stack during normal cases anyways? Most times, I don't think Iterators really lend themselves well to doing multi-threaded operations anyways. I see in ACCUMULO-533 when you added the SynchronizedIterator, you didn't see any performance impact. I'm wondering if it would make sense to add an option to the client API that allows configuration of the SynchronizedIterator (or the filter as your patch changes it to be). Thoughts?

> improve system iterator performance by collapsing call stack
> ------------------------------------------------------------
>
>                 Key: ACCUMULO-3079
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3079
>             Project: Accumulo
>          Issue Type: Improvement
>            Reporter: Adam Fuchs
>            Assignee: Adam Fuchs
>             Fix For: 1.6.1, 1.7.0
>
>         Attachments: iterator_performance_20140822_1.patch, iterator_performance_test_harness.tar.gz
>
>
> System iterators are at the core of the tightest loops in Accumulo, handling every key/value pair that traverses through a scan or a compaction. In many cases, iterators are the current performance bottleneck for Accumulo. Every bit that we can improve performance in the iterators translates into better performance for Accumulo.
> There are several strategies that can be applied to the current code base to improve performance, including:
>  # Inlining calls that are hard for the JVM to inline at runtime
>  # Moving checks for null outside of tight loops when they are invariants within the loop
>  # Eliminating "no-op" iterators at iterator tree construction time
>  # Making frequently used and assigned-once objects final (like iterator sources)


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)