Your Privacy Matters: We use our own and third-party cookies to improve your experience on our website. By continuing to use the website we understand that you accept their use. Cookie Policy
510
High memory usage after expand all
posted

We have a LoadOnDemand grid bound to an Ultra Data Source. Before the UDS loads all of its data it builds the data structure - creating all the bands that will be needed. We create 125 bands as child bands of "Band" - root level band.

Once the bands have been created we create the 1000 rows. Each of the 1000 rows has at least one child row which can go into any of the 125 bands.

There are approximately 75 columns in each band.

We click expand all and notice the memory increases by well over 200MB.

When profiling we notice this is down to a lot of RowsCollections being created (93MB attributed to them alone) and they are referenced by the DisplayLayout. We then collapse all the rows and the RowsCollections or memory do not go down.

 

Can you help us understand why so much memory would be used in our system when we expand all rows (not recursively) and why the memory would not go back down after collapsing - and waiting for a GC / forcing one?

  • 469350
    Offline posted

    Hi,

    Do you have 1000 rows in total? Or 1000 root-level rows?

    If you have a root band with 125 child bands, then that means that for every root-level row, you have 125 child rows collections (almost all of which will be empty, but that doesn't stop the colection from being created once you expand the parent row).

    Once those collections are created, the grid cannot just assume that they are not needed, so it holds on to them for performance reasons - it will never throw them away, regardless of the expanded state of the parent row.

    Having 125 child bands it probably not a good idea if you are concerned about memory usage or performance. Why do you need so many child bands? I assume it's because you need to display different columns under each parent row, but do you really need 125 completely different combinations of columns? Perhaps you could re-use the same child band for different things?

    Another option might be to use UltraWinTree. The UltraWinGrid is not really designed for working with heterogenous data, but the UltraWinTree can handle this better. The down side is that the tree doesn't have support for filtering or summaries.