phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-4004) Assorted improvements to reduce garbage in mutable index codepath
Date Sun, 09 Jul 2017 21:19:00 GMT


Lars Hofhansl commented on PHOENIX-4004:

Minor nits:
-    Collection<Pair<Mutation, byte[]>> indexUpdates = new ArrayList<Pair<Mutation,
+    // Avoid multiple internal array resizings. Initial size of 64, unless we have fewer
cells in the edit
+    int initialSize = Math.min(edit.size(), 64);

Why not just set it to edit.size()? Looking at the code, we'll never add more cells to {{indexUpdates}}
than there are cells in the edit. Not need to have a minimum of 64.

+    // Avoid the Object overhead of the executor when it's not actually parallelizing anything.
+    ArrayList<Pair<Mutation, byte[]>> results = new ArrayList<>(mutations.size());
+    for (Mutation m : mutations) {
+      results.addAll(delegate.getIndexUpdate(m, indexMetaData));
+    }
+    return results;
+  }
+  // Essentially unused due to the deadlock described in PHOENIX-2671. Leaving for posterity..
+  public Collection<Pair<Mutation, byte[]>> getIndexUpdateWithPool(

Just remove it. Posterity/history is what git is for :)
Also can get rid of the {{pool}} member and remove the constructor now.

> Assorted improvements to reduce garbage in mutable index codepath
> -----------------------------------------------------------------
>                 Key: PHOENIX-4004
>                 URL:
>             Project: Phoenix
>          Issue Type: Improvement
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>            Priority: Minor
>             Fix For: 4.12.0
>         Attachments: PHOENIX-4004.001.patch
> During some $dayjob testing, I found a couple of places where we were unnecessarily creating
garbage in the RS. When "forward-porting" this change, most of the areas were already cleaned
up but there are a few that still apply.
> * ArrayList initial sizing
> * Avoid indirection of the (single-threaded) ExecutorService in IndexBuildManager (just
pure overhead)
> * Some unnecessary KeyValue copies and an array copy (an avoidance of deprecated HBase
> * Avoid extra {{System.arraycopy}} calls in CoveredColumnIndexCodec via the {{ArrayUtils.addAll}}

This message was sent by Atlassian JIRA

View raw message