accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Fuchs (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-3079) improve system iterator performance by collapsing call stack
Date Tue, 02 Sep 2014 19:39:23 GMT


Adam Fuchs commented on ACCUMULO-3079:

Good question on the compaction scope changes. Since IteratorUtil is used in all scopes, the
attached patch does remove the synchronization from the compaction scope. We don't generally
do visibility filtering in the compaction scope, so I don't suppose the security vulnerability
applies. Do you see any reason why we would need synchronization on the compaction scope?

bq. I was really wondering if it even makes sense to "encourage" users to write multi-threaded

I don't believe I have ever come across a use case in which multiple threads are needed (or
useful) within an iterator either. From a security perspective, another approach to solving
this problem would be to use the java SecurityManager to prevent iterators from using multiple

> improve system iterator performance by collapsing call stack
> ------------------------------------------------------------
>                 Key: ACCUMULO-3079
>                 URL:
>             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
>  # 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

View raw message