[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