[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mondrian
Subject:    Re: [Mondrian] Visualizing expression evaluation /
From:       Eric McDermid <mcdermid () stonecreek ! com>
Date:       2009-02-11 1:13:29
Message-ID: BC912A3E-3A54-4408-BFC4-FCB31A4CB10F () stonecreek ! com
[Download RAW message or body]

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@gmail.com] On
>> Behalf Of Eric McDermid
>> Sent: Tuesday, February 10, 2009 4:34 PM
>> To: jhyde@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
>>
>>
>>
>
>


_______________________________________________
Mondrian mailing list
Mondrian@pentaho.org
http://lists.pentaho.org/mailman/listinfo/mondrian
[prev in list] [next in list] [prev in thread] [next in thread]