Hi,
In a windows application we have used Ultra Win Grid (version: 10.1). To this we are binding a dataset at with 1000 Records and around 70 columns. This 1000 records when binded to the grid memory used is around 10 to 20MB. (More an approximate number)When the same data is binding in a Tree / Heirarchy format the memory useage shoots up.
Requirement: Data should be shown in an Heirarchy. The heirarchy may go down to more than 250+ levels. (You can always question which user will have a look till this level, but this is the requirement)
In our scenario the heirarchy is achieved by having the data split across data tables (In this ex: 400 tables) and all these tables added to a single dataset. Relation ship between tables is added to get the heirarchy.
When the dataset is assigned to the Grid DataSource and first row is activated the memory useage is around 600MB. Is this usage justified? (Also tried using UltraDataSource, same issue and another thing we noticed the performance was slower than Datatable for achiving the same result)
Using an ANTS profiler we have ruled out any memory leaks. The profiler suggests one of the Class which takes up chuck of memory is RBTee<K>+Node<int> as show in the attached screenshot. This is more a system object (part of System.Data namespace) and not a custom code.
Just wondering if the memory useage is justified or not. Secondly is there any better implementation?
Narasimha
Hi Mike,
Actually i had got the levels wrong.... the level can grow upto 10 to 12 and 250. Few options we implemented to come up with better memory management:
1. Reduced the number of columns
2. After binding to release the memory used calling a windows API function : ReduceWorkingSet & SetProcessWorkingSetSize. This approach something which i found on one of the forum links.
3. Created another screen to implement the same functionality and instead of using Win Grid have implemented it through Win Tree. The third approach has considerably reduced the memory useage for the same set of records (1000) and showing all the levels.
Just wanted to update the post with the implementation approach we took....
Thanks everyone for taking time out and replying to my post.
There are several things you need to consider here.
First, 250 levels deep is not a reasonable number. No user could possibly handle so much data in the UI. I'm not sure why that is a requirement for your application, but I would be surprised if this was possible for any control. In my experience, the DotNet BindingManager will start slowing down after about 5 levels, and becomes unusable between 8 and 10 - depending on the machine specs, memory, speed, etc.
The grid has a MaxBandDepth property which defaults to 100, so your 250 levels are probably only showing up to level 100, anyway. But even this is not realistic.
If memory usage is a concern, then you could try using the grid with an UltraDataSource in on-demand mode. There's a sample called the Virtual mode sample which demonstrates how to load the data into the UltraDataSource and thus into the grid as-needed, instead of all at once. This will save you save memory up front, but once the user starts drilling down 10 or more levels deep, I would not be at all surprised if your application ran into some very severe performance problems.
Another option you might consider is using UltraWinTree instead of UltraWinGrid. The tree creates the BindingManagers it needs only when the particular level of data is needed. Once again, this will save you some memory up-front, but drilling down more than 10 levels or so is likely to run into performance problems just as it does in the grid.
I recommend that you check out the WinGrid Performance Guide. There may be some tips there that can help you lower the grid's memory usage.
Thanks for the update.
UltraGrid has been optimized for performance and is about as conservative as it can be with memory consumption. 400 tables in one DataSet is an enormous number, and I'm not suprised that it causes a 600MB drain on memory. If you bind the MS hierarchical grid to something that big my guess is you will see a similar result.