[
https://issues.apache.org/jira/browse/TAJO-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14108014#comment-14108014
]
ASF GitHub Bot commented on TAJO-906:
-------------------------------------
Github user hyunsik commented on the pull request:
https://github.com/apache/tajo/pull/113#issuecomment-53154532
Hi @blrunner,
If CODEGEN session variable is enabled, all queries will work by using code
generation. But, currently, we cannot expect its performance improvement. The
code generation is designed to avoid Datum objects creations during any
computations and reduce interpretation overheads like branches.
But, in order to keep the compatibility against our current Tuple and Datum
mechanism, code generation feature still create lots of Datum objects.
Currently, I'm working new tuple structure using direct memory, which uses a
sequence of bytes as a row blocks instead of an array of Datum objects. After
than, it will give big performance benefits.
Thanks!
> Runtime code generation for evaluating expression trees
> -------------------------------------------------------
>
> Key: TAJO-906
> URL: https://issues.apache.org/jira/browse/TAJO-906
> Project: Tajo
> Issue Type: Improvement
> Components: physical operator
> Reporter: Hyunsik Choi
> Assignee: Hyunsik Choi
> Fix For: 0.9.0
>
>
> We have used EvalNode for two purposes:
> * logical planning of expressions
> * evaluation of expressions
> EvalNode still is very nice for the purpose of logical planning. But, each
> EvalNode tree takes Datum included in a tuple and results in a Datum as a
> evaluation result.
> So, the current approach requires many object creations, and causes interpret
> overheads, meaning that each one evaluation involves tree traverses and many
> function calls. interpretation involves also many branches, and it is harmful
> to CPU pipelining.
> I propose Java byte code generation for each expression, and I'll use ASM
> (http://asm.ow2.org/) for it. This approach will write native java byte code,
> eliminating many condition branches and function calls. In addition, it is
> easier to deal with java primitive data types for expressions.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
