[Mondrian] Visualizing expression evaluation / optimizingcalculations

Eric McDermid mcdermid at stonecreek.com
Tue Feb 10 20:13:29 EST 2009


Aargh.  I'd gotten thrown off because of a difference between 2.4 and  
3.01 (GenericCalc implements TupleCalc in 3.1, but not in 2.4, and in  
my local version TupleCalc is what was failing with the  
ClassCastException).

Thanks for the help.

  -- Eric

On Feb 10, 2009, at 5:46 PM, Julian Hyde wrote:

> The trick is that GenericCalc implements everything. Or almost  
> everything.
>
>> -----Original Message-----
>> From: Eric McDermid [mailto:mcdermidmobile at gmail.com] On
>> Behalf Of Eric McDermid
>> Sent: Tuesday, February 10, 2009 4:34 PM
>> To: jhyde at pentaho.com; Mondrian developer mailing list
>> Subject: Re: [Mondrian] Visualizing expression evaluation /
>> optimizingcalculations
>>
>>
>> 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