We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy. Image for the cookie policy date
close icon

GridGroupingControl - memory problems, taking more footprint memory

Hi All, We are having memory problems with GGC. When I run the application and check for process memory in the task manager, i could see lots of memory being used. But when I minimize the application, i could see lot of reduction in memory. When i put a break point in grdCallSheet_QueryCellStyleInfo event, i could see it repeated calls to it when I maximize, scroll in the grid etc. I think each cell (in display) is being repainted/re-styled again and again. I am yet to check if there are other such synchfusion events, as I am using many other synchfucion controls. Cant we avoid this repeated calls? which can save lots of memory. Any insight please.. Rgds Rajani Kanth

5 Replies

AD Administrator Syncfusion Team November 17, 2005 12:59 PM UTC

I think your first observation is strictly a function of the .NET Framework. The memory management is all done by the framework. It controls when it will release memory. Minimizing a .NET application causes the framework to reduce its memory footprint to the size that is actually currently required. Theoretically, if another process required memory, the .NET Framework would then release unneeded memory so it would then be available. So, just because the memory use is indicated in taskManager, it does not mean that it is not available. If minimizing the app frees it up, then it is available if needed. QueryCellStyleInfo is hit repeatedly, many, many times. This is by design and cannot be avoided in a GridGroupingControl. Any code you place in there needs to be optimized as much as possible if you are seeing performance problems. The styles used in QueryCellStyleInfo arguments are weak references that will be automatically released the first time garbage collections kicks in. If you creating objects in the code that you have added to QueryCellStyleInfo, then that may be another matter.


BR Badri Rajani Kanth November 17, 2005 04:05 PM UTC

But surprisngly, when I minimize and then maximize the application, the intial memory and current memory varies a lot. For example, 106596K is the initial memory. 2260K is memory when minimized and 13300K is when maximized. We can observe the difference 13300K to initial 106596K..isn''t it? any clue? Rgds rajani kanth >I think your first observation is strictly a function of the .NET Framework. The memory management is all done by the framework. It controls when it will release memory. Minimizing a .NET application causes the framework to reduce its memory footprint to the size that is actually currently required. Theoretically, if another process required memory, the .NET Framework would then release unneeded memory so it would then be available. So, just because the memory use is indicated in taskManager, it does not mean that it is not available. If minimizing the app frees it up, then it is available if needed. > >QueryCellStyleInfo is hit repeatedly, many, many times. This is by design and cannot be avoided in a GridGroupingControl. Any code you place in there needs to be optimized as much as possible if you are seeing performance problems. The styles used in QueryCellStyleInfo arguments are weak references that will be automatically released the first time garbage collections kicks in. If you creating objects in the code that you have added to QueryCellStyleInfo, then that may be another matter. > >


AD Administrator Syncfusion Team November 17, 2005 05:25 PM UTC

During the initial loading of the data, the grid builds data structures to hold the final categorized data in a balanced tree structure. This work requires memory that is no longer required when it is completed. The act of minimizing the application forces the .NET framework to release this no longer needed memory. It otherwise would not have been released until the framework/OS got around to releasing it.


SR Soumen Roy December 22, 2005 02:02 PM UTC

I ran TraderGridTest Sample under Performance. It was taking on an average 37-40% of the CPU cycles on maximized screen. My application runs with TIBCO subjects - that receives thousands of messages from TIBCO every second and use 18- 23% of the CPU cycles. I am worried if I use Grouping Grid it will increase the CPU to above 50% - that is not good for Traders. Could you please optimize the sample to use less CPU cycles without changing the Calculation logic. Our current application is running with Grid and we are facing problem with the Initial memory (over 250MB) usage by the Grid. If we minimize and restore the application, the memory usage dropped to 47 MB and it ramains there for some time at least for 10 Minutes - with heavy trading traffic, I mean just before market close. We need a solution where both CPU cycle and Memory usage is optimized.


AD Administrator Syncfusion Team December 28, 2005 10:09 AM UTC

Hi Soumen, With the 4.1 release, we have a similar solution for GGC ie., using cached graphics context and calling DrawClippedGrid for drawing. Please refer this sample for more details: Syncfusion\Essential Studio\4.1.0.10\windows\Grid.Grouping.Windows\Samples\RealtimeUpdates Best regards, Jay

Loader.
Live Chat Icon For mobile
Up arrow icon