drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DRILL-3912) Common subexpression elimination in code generation
Date Tue, 20 Oct 2015 00:39:28 GMT

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

ASF GitHub Bot commented on DRILL-3912:
---------------------------------------

Github user jinfengni commented on a diff in the pull request:

    https://github.com/apache/drill/pull/189#discussion_r42444043
  
    --- Diff: exec/java-exec/src/main/java/org/apache/drill/exec/expr/EvaluationVisitor.java
---
    @@ -106,19 +163,32 @@ public HoldingContainer visitFunctionCall(FunctionCall call, ClassGenerator<?>
g
         @Override
         public HoldingContainer visitBooleanOperator(BooleanOperator op,
             ClassGenerator<?> generator) throws RuntimeException {
    +      HoldingContainer hc = getPrevious(op);
    +      if (hc != null) {
    +        return hc;
    +      }
    +      newScope();
    --- End diff --
    
    Is it possible to move the call of newScope() and leaveScope() to ClassGenerator.nestEvalBlock(),
unnestEvalBlock()? Those two methods would essentially create / remove a new nested scope
in the code, and is actually called for BooleanOperator (and/or) and IfExpression. 
    
    Otherwise, we have to remember to call newScope() / leaveScope() everywhere the codes
creates/delete a new scope, which seems to be error-prone.
     


> Common subexpression elimination in code generation
> ---------------------------------------------------
>
>                 Key: DRILL-3912
>                 URL: https://issues.apache.org/jira/browse/DRILL-3912
>             Project: Apache Drill
>          Issue Type: Bug
>            Reporter: Steven Phillips
>            Assignee: Jinfeng Ni
>
> Drill currently will evaluate the full expression tree, even if there are redundant subtrees.
Many of these redundant evaluations can be eliminated by reusing the results from previously
evaluated expression trees.
> For example,
> {code}
> select a + 1, (a + 1)* (a - 1) from t
> {code}
> Will compute the entire (a + 1) expression twice. With CSE, it will only be evaluated
once.
> The benefit will be reducing the work done when evaluating expressions, as well as reducing
the amount of code that is generated, which could also lead to better JIT optimization.



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

Mime
View raw message