Hi
I am facing some performance issue after setting summary values to column.I takes 2-3 seconds to scroll horizontal or vertical.I have 500 unbounded columns and 50 rows(10 groupby rows) and 80 visible columns in area.I have added custom summary calculator to columns.
The thing which i want to achieve is to show different colors and text in each groupby row means one row with different color in each column(see attachment).I have used ICustomSummary calculator.I am returning just a string in EndCustomSummary method.I have tried to improve the performance by setting same customsummarycalculator in each column but it is still very slow.
Hi,
How many summaries do you have? One for each column?
If you have 500 columns, each with it's own custom summary calculator, then I'm not surprised you are experiencing some performance issues. In a case like this, the grid will have to iterate over the rows collection 500 times every time the summary is calculated. I don't see any way around that.
But... if you can post a small sample project demonstrating the behavior, I would be happy to take a look at it and see if I can find some way to improve the performance. Without a sample, though, there are just too many unknowns.
Hi I have attached the sample within.You can see the problem when groupby rows are expanded and user want to scroll vertical.So it takes time to expand row and also take time to scroll vertical and horizontal.
Another question As you can see in sample the height of groupby column is increased as SummaryDisplayStyle is set to Summarycells.You can see when you press remove summary button in sample the height is decreased.I think it is due to GroupByRowDescriptionMaskSo is it possible that groupby row height donot increase while applying summary cells to it.
Hi Steve,
Steve Liu said:Firstly, maybe I misunderstood that you meant the grid does re-calculations every time when you said "When you scroll and some new summary cells come into view, the grid has to loop through all of the rows that apply to that summary."
What I meant by this is that the summary gets calculated the FIRST time it's scrolled into view. That assumes, of course, that no one asked for the summary value prior to that, which would require it to be calculated earlier.
If you want to force the summaries to be calculated up front, you could do that very easily by simply asking for the value in code. for example, for root-level summaries, you could do this:
foreach (SummaryValue summaryValue in this.ultraGrid1.Rows.SummaryValues) { object o = summaryValue.Value; }
Of the top of my head, I can't think of any reason why scrolling should be slow the second time you scroll the sumnmary into view, but maybe there is some reason the grid needs to check to see if it's dirty and need recalculating or something. If you can provide a small sample project that demonstrates that behavior, we could look into it.
Allow me to update with some more testing result. It does seem it improved quite a bit during subsequent scrolling after first complete round of scrolling down. But still the scrolling seemed delayed somewhat, comparing to, if I remove all summary rows, the scrolling up and down will then be smooth as it should be in a normal grid.
On your point "The summaries are not calculated until the summary cell is scrolled into view (or someone asks for the value) because that would be a waste of CPU cycles to calculate something no one needs. ", I actually disagree.
If I can set it to do all calculations in the beginning, at least, I can get the report running while I go on a coffee break and come back with a useful report to scroll up and down other than now it's impossible to scroll up and down at all!
Hi Mike,
Thanks for the quick response.
Firstly, maybe I misunderstood that you meant the grid does re-calculations every time when you said "When you scroll and some new summary cells come into view, the grid has to loop through all of the rows that apply to that summary."
Secondly, I suspect that is the case because even after I did one complete round of scrolling down and up (took forever to achieve that by the way, painful!), the performance didn't seem to get much better when I try to scroll it down again. So I am suspecting some processing is still happening during second+ round of scrolling down.
Just FYI, in our case, we have 83 columns and thousands of rows of raw data plus 15 summary rows. If I turn off the 15 summary rows, scrolling up and down is not a problem. So whatever is happening, it has something to do with the summary rows.
-Steve
It might depend on whether you are using the build-in summaries or the CalcManager, but I doubt the grid re-calculates the summary every time you scroll it into view. What leads you to believe that's happening? The summaries are not calculated until the summary cell is scrolled into view (or someone asks for the value) because that would be a waste of CPU cycles to calculate something no one needs. But once they are calculated once I can't see any reason to re-calculate them unless something in the column changed.
I could be wrong about that as far as the built-in summary types are concerned, but I'm pretty sure that CalcManager summaries don't do that.