[Mondrian] Visualizing expression evaluation / optimizingcalculations
Julian Hyde
jhyde at pentaho.com
Tue Feb 10 19:46:08 EST 2009
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