Hi,

I ran your sample through the Ant Performance profiler and it looks like I was right. 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. With so many summaries, this results in something like 280,000 iterations of a loop which gets the summary value.

I don't see any way around this. This many summaries is just not going to be performant.

avlindia said:

So is it possible that groupby row height donot increase while applying summary cells to it. 

I' not sure exactly what you want here. There's no way to stop the GroupByRow from increasing in height to accommodate the summaries. If there was a way, it would end up clipping the summaries and you would not be able to see them clearly.

You can increase the height of the GroupByRow when there is no summary by setting it's Height property, of course. At least then the height would be consistent whether there is a summary or not.

Hi Mike,

I'd like to follow up on this issue as we are seeing the same issue with 2013 Infragistics UltraGrid.

Here is my question:

Why are the summary cells re-calculated every time they are scrolled into view, even for a read-only grid? Is there a setting to tell grid to calc once during initial load and don't re-calc during scrolling?

Thanks

Steve

Hi 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.

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

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.