We are using V9.2 (no service releases) and are running into some performance problems with Summaries and Grouping when using dynamic (realtime) data
Our testing scenario:
100 data rows4 levels of grouping (GroupBy columns are nearly unique, so there are ~100 groups at every level)10 columns with formulas (Simple addition formula based on a single source column we update dynamically)40 total columns
We have set the CalcManager mode to Manual. On a timer We are updating the values in the source column, and calling CalcManager.ReCalc(). This is done inside a Grid.BeginUpdate/EndUpdate block. Whether we update all the rows or a percentage the rows doesn't seem to affect the performance noticeably. What we are finding is that it takes about 2 seconds for the ReCalc() call to finish. This time increases as you add more GroupBy levels.
We assume that the summary calculations are being done in a simplistic manner which doesn't reuse any intermediate results from child GroupBy levels (essentially looping through all the data rows at every GroupBy level for every GroupBy row.) Is this true?
If we were to write a CustomSummaryCalculator, are we restricted to this model? There doesn't seem to be any easy way in the current architecture to reuse calculations or stop the summary calculation if you want. It will loop through all the rows regardless.
Has anyone written a smarter CustomSummaryCalculator for the simple summaries (Sum, Average, Max, Min). Any other options we could explore?
We are thinking about doing all of our summary calculation ourselves, but then we would run into issues of where and how to draw those in the grid.
Thanks,
Stefan
Hi Stefan,
Stefan said:We assume that the summary calculations are being done in a simplistic manner which doesn't reuse any intermediate results from child GroupBy levels (essentially looping through all the data rows at every GroupBy level for every GroupBy row.) Is this true?
Yes, I'm pretty sure that is the case.The CalcManager doesn't know enough about the grid or the nature of it's hierarchy of GroupByRow to be able to use the intermediate-level summaries. Even if it did, there's no way it could interpret the formula in such as way as to know whether using the intermediate summaries would be valid for the calculations.
Stefan said:If we were to write a CustomSummaryCalculator, are we restricted to this model? There doesn't seem to be any easy way in the current architecture to reuse calculations or stop the summary calculation if you want. It will loop through all the rows regardless.
No, I don't beleive this would help. You could, in fact, create a CustomSummaryCalculator which summed up the sums in the GroupByRows. But this would not prevent the grid from looping through the rows - it would still iterate the rows, even though your code would not be doing anything.
Stefan said:We are thinking about doing all of our summary calculation ourselves, but then we would run into issues of where and how to draw those in the grid.
To a certain extent, this can be done. What I would do is create a formula summary with a literal value in it. For example, you could use a formula of "0". Whenever the summary needs to be recalculated, you simple change the formula of the summary to the literal value you want the grid to display.
The only question then is, when do you recalculate it? You would basically have to handle any methods or events which would cause the value of the summary to change and either recalculate it at that point, or just bump a version number and then recalculate the next time something in your code or on the screen needs the summary value. How you do this depends on your application.