[
https://issues.apache.org/jira/browse/CALCITE-7794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18116577#comment-18116577
]
Michael Braun commented on CALCITE-7794:
----------------------------------------
[~julianhyde] I've added benchmark numbers to the PR. Positive but close to
neutral in the rules==1 case, much better if more than one rule. Some redundant
operations were being done across every rule, and the primary change was to
move that check up and also short circuit more eagerly.
> Reduce the work HepPlanner does per rule application attempt
> ------------------------------------------------------------
>
> Key: CALCITE-7794
> URL: https://issues.apache.org/jira/browse/CALCITE-7794
> Project: Calcite
> Issue Type: Improvement
> Reporter: Michael Braun
> Priority: Minor
> Labels: pull-request-available
>
> HepPlanner tries every rule in a collection against every vertex, so missed
> attempts
> can greatly outnumber matches.
> On every attempt, {{applyRule}} tests {{graph.vertexSet().contains(vertex)}}.
> Both
> call sites try every rule against the same vertex in a loop that only exits
> early on
> a match, so membership cannot change within it: 100 rules means 100 set
> lookups
> where one would do.
> On attempts that cannot match -- the large majority -- {{applyRule}} also
> allocates
> {{bindings}} and {{nodeChildren}} before calling {{matchOperands}}, which
> rejects on
> its first statement, and runs the {{ConverterRule}} and
> {{CommonRelSubExprRule}}
> branches, traversing a vertex's parents, before the operand is tested.
> Proposed: move the membership test to the two callers, which need it once per
> vertex;
> return early for an empty rule collection; and test the operand first in
> {{applyRule}}, splitting {{matchOperands}} into a thin entry point making
> that test
> and a body assuming it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
