[Mondrian] RolapEvaluator.push()

[Joe Barnett]

On Wed, Jan 19, 2011 at 11:00 PM, Julian Hyde <jhyde at pentaho.com> wrote:
>> Joe wrote:
>>
>> After spending the past few months looking at mondrian profiles, it
>> definitely seems like optimizing RolapEvaluator.push() would be a big
>> win.  Both RolapEvaluator.push() and RolapEvaluator.setContext() show
>> prominently as being called from just about everywhere in the call
>> stack -- thousands or milllions of invocations per query execution.
>> Would just have to measure the before and after to be sure that
>> push()-as-copy with no pop is actually slower than
>> push()-onto-stack-and-then-rollback; seems like it should be, but you
>> never know with these types of changes...  Even if it ends up being
>> approximately the same, though, IF the cellrequest construction can be
>> dramatically sped up by precomputing it in the evaluator, that part of
>> it sounds the most promising, based on cellrequest construction &
>> lookup being some of the largest parts of the profiles I've been
>> looking at.  Would be a 3.3-timeframe change, or would it have to wait
>> until 4.0?  (tangentially related question: should I be working on the
>> parallel execution stuff in 3.3 or somewhere else?)
>
> Glad you agree that this change would be worthwhile.
>
> I am making this change in //open/mondrian (i.e. the mainline) that will be
> for release 3.3. It's in the category "minimal API changes -- except
> possibly for UDFs -- but possibly will introduce bugs". 3.3's beta period
> should be sufficient to shake out bugs.
>
> I think you should work on the same branch.
>
> By the way, I still intend to respond to your comments on
> http://jira.pentaho.com/browse/MONDRIAN-874. It's been over a week and I
> haven't responded yet -- sorry about that. I know this change, and my recent
> change to combine MemberListCalc and TupleListCalc, conflict with your
> proposed changes in that jira case. But as you no doubt realise, both of
> these changes were inspired by the performance problems that you have been
> trying to solve. I hope that they will be complementary. I realised that
> architectural changes were needed, and that we would get a better outcome if
> we put those changes in place as early as possible, then iterate.
>
> Julian
>
>

Ok, cool.  Looking forward to your futher comments when you are able
to respond.  I've got a bunch of non-mondrian stuff I'm working on
right now, but once I get back to it, will switch over to the
//open/mondrian branch.  No problem about the conflicts that will
happen; I've got a few that I'm dealing with between 3.2.0 release
(which we'll be starting to test for shipping to production soon) and
latest //open/mondrian-3.2 anyway.  Agree on getting the architectural
changes in as soon as possible, and then I'll try layering on top of
that.

-Joe