[
https://issues.apache.org/jira/browse/IMPALA-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Rogers updated IMPALA-7808:
--------------------------------
Description:
The analysis steps in {{SelectStmt}} and {{AnalysisContext}} are large and
cumbersome. There is ample evidence in the literature that simpler, smaller
functions are easier to understand and debug than larger, more complex
functions. This ticket requests breaking up the large functions in these two
cases into smaller, easier-understood units in preparation for tracking down
issues related to missing rewrites of the {{WHERE}} and {{GROUP BY}} clauses.
One might argue that large functions perform better by eliminating unnecessary
function calls. However, the planner is not performance sensitive, and the
dozen extra calls that this change introduce will not change performance given
the thousands of calls already made.
Experience has shown that the JIT compiler in the JVM actually does a better
job optimizing smaller functions, and gives up when functions get to large. So,
by creating smaller functions, we may actually allow the JIT compiler to
generate better code.
And, this refactoring is in support of a likely outcome that the planner can
handle rewrites without making multiple passes through the analyzer: that
savings will far outweigh the few extra calls this change introduces.
was:
The analysis steps in {{Analyzer}} and {{AnalysisContext}} are large and
cumbersome. There is ample evidence in the literature that simpler, smaller
functions are easier to understand and debug than larger, more complex
functions. This ticket requests breaking up the large functions in these two
cases into smaller, easier-understood units in preparation for tracking down
issues related to missing rewrites of the {{WHERE}} and {{GROUP BY}} clauses.
One might argue that large functions perform better by eliminating unnecessary
function calls. However, the planner is not performance sensitive, and the
dozen extra calls that this change introduce will not change performance given
the thousands of calls already made.
Experience has shown that the JIT compiler in the JVM actually does a better
job optimizing smaller functions, and gives up when functions get to large. So,
by creating smaller functions, we may actually allow the JIT compiler to
generate better code.
And, this refactoring is in support of a likely outcome that the planner can
handle rewrites without making multiple passes through the analyzer: that
savings will far outweigh the few extra calls this change introduces.
> Refactor Analyzer for easier debugging
> --------------------------------------
>
> Key: IMPALA-7808
> URL: https://issues.apache.org/jira/browse/IMPALA-7808
> Project: IMPALA
> Issue Type: Improvement
> Components: Frontend
> Affects Versions: Impala 3.0
> Reporter: Paul Rogers
> Assignee: Paul Rogers
> Priority: Minor
>
> The analysis steps in {{SelectStmt}} and {{AnalysisContext}} are large and
> cumbersome. There is ample evidence in the literature that simpler, smaller
> functions are easier to understand and debug than larger, more complex
> functions. This ticket requests breaking up the large functions in these two
> cases into smaller, easier-understood units in preparation for tracking down
> issues related to missing rewrites of the {{WHERE}} and {{GROUP BY}} clauses.
> One might argue that large functions perform better by eliminating
> unnecessary function calls. However, the planner is not performance
> sensitive, and the dozen extra calls that this change introduce will not
> change performance given the thousands of calls already made.
> Experience has shown that the JIT compiler in the JVM actually does a better
> job optimizing smaller functions, and gives up when functions get to large.
> So, by creating smaller functions, we may actually allow the JIT compiler to
> generate better code.
> And, this refactoring is in support of a likely outcome that the planner can
> handle rewrites without making multiple passes through the analyzer: that
> savings will far outweigh the few extra calls this change introduces.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
