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

Misha Dmitriev commented on HIVE-19937:
---------------------------------------

The last patch looks good to me.

The only slight concern that I got from looking at it once again is the 
following: in one or two places you switched from passing around Strings to 
passing around Paths, and subsequently switched someĀ  HashMap(s)<String, 
Something> to HashMap<Path, Something>. Note that a lookup in a map where keys 
are complex objects is slower, because Path.equals(Path) is slower than 
String.equals(String) - it may involve comparison of many strings, etc. I 
haven't seen any reports on Hive CPU performance problems, and I hope this code 
is not on a critical path, and/or that GC-related savings would offset the 
potential hashmap lookup slowdown... but anyway, I guess it's worth remembering 
about this.

> Intern fields in MapWork on deserialization
> -------------------------------------------
>
>                 Key: HIVE-19937
>                 URL: https://issues.apache.org/jira/browse/HIVE-19937
>             Project: Hive
>          Issue Type: Improvement
>          Components: Spark
>            Reporter: Sahil Takiar
>            Assignee: Sahil Takiar
>            Priority: Major
>         Attachments: HIVE-19937.1.patch, HIVE-19937.2.patch, 
> HIVE-19937.3.patch, HIVE-19937.4.patch, HIVE-19937.5.patch, 
> post-patch-report.html, report.html
>
>
> When fixing HIVE-16395, we decided that each new Spark task should clone the 
> {{JobConf}} object to prevent any {{ConcurrentModificationException}} from 
> being thrown. However, setting this variable comes at a cost of storing a 
> duplicate {{JobConf}} object for each Spark task. These objects can take up a 
> significant amount of memory, we should intern them so that Spark tasks 
> running in the same JVM don't store duplicate copies.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to