[Mondrian] Changing the mondrian development process to prevent performance slippages
jhyde at pentaho.org
Sun Mar 30 20:00:30 EDT 2008
> John Sichi wrote:
> RE: [Mondrian] Adding Grouping Set support for Distinct Count measures
> In eigenchange 10766, I changed AggregateFunDef to allow it
> to skip the
> list reduction methods added by Ajit (on a per dialect
> basis), because
> they are really slow.
I'm beginning to think that I need to start running a tighter ship as
regards performance. There have been several alleged performance slippages
over the past year, but we've not caught them effectively. Our process is
not strong enough to detect them at the time they are made, and after the
event it is too difficult to figure out which change out of many caused
performance to sutffer.
So, please, I'd like to hear suggestions for how we can change our process.
It can't be purely a process change, because I don't personally have enough
time/discipline to review each change as it is made and test its performance
effects; there has to be some technology involved. Developers are
responsible for ensuring that their change doesn't degrade performance, even
on platforms that are not of interest to them personally, but it isn't
enforced, so slippages occur. So we need a way to enforce that changes don't
degrade performance, just as we have a regression suite to ensure that other
aspects of mondrian's behavior are preserved.
Since LucidEra and Thomson/Thoughtworks are the two largest groups besides
Pentaho who have an interest in developing mondrian, I would like those two
groups in particular to step up with suggestions and offers of help. Pentaho
can provide resources to run the process and publish results, but can only
offer limited leadership.
More information about the Mondrian