Mailing-List: contact dev-help@crunch.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@crunch.apache.org
Date: Mon, 18 Apr 2016 19:45:25 +0000 (UTC)
From: "Steven Ruppert (JIRA)" <jira@apache.org>
To: crunch-dev@incubator.apache.org
Message-ID: <JIRA.12959771.1461008711000.259461.1461008725503@Atlassian.JIRA>
In-Reply-To: <JIRA.12959771.1461008711000@Atlassian.JIRA>
References: <JIRA.12959771.1461008711000@Atlassian.JIRA>
 <JIRA.12959771.1461008711945@arcas>
Subject: [jira] [Created] (CRUNCH-604) Avoid expensive
 Writables.reloadWritableComparableCodes where possible
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Steven Ruppert created CRUNCH-604:
-------------------------------------

             Summary: Avoid expensive Writables.reloadWritableComparableCodes where possible
                 Key: CRUNCH-604
                 URL: https://issues.apache.org/jira/browse/CRUNCH-604
             Project: Crunch
          Issue Type: Improvement
          Components: Core
    Affects Versions: 0.13.0
            Reporter: Steven Ruppert
            Assignee: Josh Wills


Every time `setConf` is called on TupleWritable, `Writables.reloadWritableComparableCodes(conf)` is called. Unfortunately, `SequenceFile$Reader.readValue` calls `setConf` every single time. This burns a regrettable amount of CPU time.

Attached is a patch that prevents a given TupleWritable instance from reloading the code more than once, as well as a patch to cache (hashCode-wise) reading from the actual hadoop config, which has to run regexes and stuff. I can construe situations where this would break (somehow, you modify the configuration in between reading to two values), but nothing actually sane comes to mind.


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