[Mondrian] Visualizing expression evaluation / optimizingcalculations
Eric McDermid
mcdermid at stonecreek.com
Tue Feb 10 19:33:56 EST 2009
On Feb 3, 2009, at 8:20 PM, Julian Hyde wrote:
>
>> First, is it reasonable to assume that the performance gain is a
>> result of simply specifying the most restrictive subcondition in the
>> filter first?
>
> That would be my guess. To test it, add a wrapper that extends
> GenericCalc
> and counts the number of executes. Then add a tracer that prints the
> calc
> tree after execution with the number of times that each calc is
> called.
>
> To add those extra wrapper calcs, write a subclass of ExpCompiler.
> DteCompiler does something similar already, so follow its example.
I've been looking into this, and something seems a little odd.
DteCompiler extends DelegatingExpCompiler, which simply calls
afterCompile() on each compiled calc and returns the result.
DelegatingExpCompiler.afterCompile() is essentially a no-op, but
DteCompiler.afterCompile() creates a new instance of a wrapper class
(either DteScalarCalcImpl or DteIterCalcImpl, extending GenericCalc
and GenericIterCalc respectively) around each calc and returns the
wrapper.
What's throwing me is that each of the compile methods of
DelegatingExpCompiler casts the result of afterCompile() to the type
of the original calc that's just been wrapped, which should always
result in a ClassCastException. For example:
public MemberCalc compileMember(Exp exp) {
MemberCalc calc = parent.compileMember(exp);
return (MemberCalc) afterCompile(exp, calc, false);
}
The lone exception to this pattern is
DelegatingExpCompiler.compileScalar(), which simply returns Calc.
Am I missing some sleight-of-hand that allows this all to work, or is
it just that these compile<xxx>() methods never actually get invoked?
-- Eric
More information about the Mondrian
mailing list