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

Jacques Nadeau commented on ARROW-1463:
---------------------------------------

It seems like there a milestone here that we should figure out.

# Come up with a set of goals (we can use this jira to describe potential 
places for improvement)
# Propose an object hierarchy (I think there may be a jira that Julien wrote 
that covers this.)
# Prototype a couple vectors to evaluate against goals (I suggest having maybe 
two people do this in parallel to see what different ideas people come up).
# Implement the updated vectors.

I see [~siddteotia] assigned this to himself. I'd like to also make sure we 
have others involved in these subtasks and would like to break them out here. 
Other opinions on subtasks we should have? [~bryanc] and/or [~icexelloss] 
either of you interested in working on pieces of this? Definitely think it is 
overdue.


> [JAVA] Restructure ValueVector hierarchy to minimize compile-time generated 
> code
> --------------------------------------------------------------------------------
>
>                 Key: ARROW-1463
>                 URL: https://issues.apache.org/jira/browse/ARROW-1463
>             Project: Apache Arrow
>          Issue Type: Improvement
>            Reporter: Jacques Nadeau
>            Assignee: SIDDHARTH TEOTIA
>
> The templates used in the java package are very high mainteance and the if 
> conditions are hard to track. As started in the discussion here: 
> https://github.com/apache/arrow/pull/1012, I'd like to propose that we modify 
> the structure of the internal value vectors and code generation dynamics.
> Create new abstract base vectors:
> BaseFixedVector
> BaseVariableVector
> BaseNullableVector
> For each of these, implement all the basic functionality of a vector without 
> using templating.
> Evaluate whether to use code generation to generate specific specializations 
> of this functionality for each type where needed for performance purposes 
> (probably constrained to mutator and accessor set/get methods). Giant and 
> complex if conditions in the templates are actually worse from my perspective 
> than a small amount of hand written duplicated code since templates are much 
> harder to work with. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to