[Mondrian] RolapEvaluator.push()

[Julian Hyde]

> 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