Severe Memory Leak
Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Report Control
Forum Description: Topics Related to Codejock Report Control
URL: http://forum.codejock.com/forum_posts.asp?TID=7921
Printed Date: 14 May 2024 at 4:03am
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com
Topic: Severe Memory Leak
Posted By: dhugal
Subject: Severe Memory Leak
Date Posted: 03 September 2007 at 3:20am
|
We have been using the Code Jock controls for some time but just recently our application seems to be using a lot lot more ram. I did some investigation and it appears that when we use the Report Grid control and add a lot of items where we set the caption to be different from the value (we do this for all numeric & date fields because we format them nicely for the user) the grid exhibits a severe memory leak. I have put together an example project demonstrating this: https://forum.codejock.com/uploads/20070903_032029_ReportControlMe.zip - uploads/20070903_032029_ReportControlMe.zip
If you fill the grid with 20,000 rows each the control consumes a fair amount of ram as expected - when you then clear it all of that ram is freed (correction - most). If however you fill it with the same number of rows and explicitely set the caption on each of the values the grid consumes a lot of ram again but when you clear it is not all freed - in fact a large percent is never freed. When I am running this in a VB6 IDE the ram isn't even freed when I close the application and I have to terminate the IDE to free it.
The memory figures (KB) with 20,000 records / 40 Columns are as follows: Project started in IDE and form displayed: 14,920 App closed return to VB design environmentGrid then cleared: 129,380 (We have still not reclaimed the missing 100 meg!)
This is obviously very urgent for us as we are using this with a very high number of users in a Terminal Services environment so any memory leaks result in degredation of the server performance and eventual crashes in our application. Can you give me an estimate for a fix please? Dhugal. |
Replies:
Posted By: dhugal
Date Posted: 04 September 2007 at 12:31pm
|
Is there any response on this?
I have made a support request - no response.
I have tried phoning you guys on the international number all afternoon - no answer (12 noon EST).
Please help me!
|
Posted By: mav46
Date Posted: 07 September 2007 at 10:05am
|
yes, it's true. I'have realize it on one of my projects. I have the same memory leak when I populate the report control with a custom caption on all the filed of the report .....
There is a urgent need to solve this bug, please.
------------- Product: Xtreme SuitePro (ActiveX) 12.1.1 Platform: Win XP (32bit) Language: Visual Basic 6.0 SP5 |
Posted By: mav46
Date Posted: 17 September 2007 at 10:54am
|
... any idea CJ team ? ------------- Product: Xtreme SuitePro (ActiveX) 12.1.1 Platform: Win XP (32bit) Language: Visual Basic 6.0 SP5 |
Posted By: sserge
Date Posted: 20 September 2007 at 5:42pm
|
Copying there an answer to this question from support area: The problem is related to MFC 6.0 CString implementation. CString objects have internal cache and do not deallocate memory when string is destroyed. Their memory is kept in the cache and reused in the feature string allocations. (This was useful in the old windows versions) This is not a leak, just such behavior. You can click Fill and Clear many times and see that used memory will not grow and grow as for the leak. I see only one way to fix this - use MFC 8.0 OCX build. MFC 8.0 CString implementation has no such cache. Also to optimize memory usage you can enable the following features: Private Sub Form_Initialize() ReportControlGlobalSettings.UseReportCustomHeap ReportControlGlobalSettings.UseBatchAllocation End Sub Also you may use ReportControlGlobalSettings.FreeBatchExtraData after remove all data to free cached memory. -- WBR, Serge |
Posted By: sserge
Date Posted: 20 September 2007 at 5:43pm
|
Some more information: Report control has 2 features to optimize memory usage. This is useful for big amount of records (more than 10 000). Let me note that features described below has real effect in Release build only. In Debug build, program which used these features may work even slower than without them. 1. Custom Heap. Some Report Control classes, which represent data (records, record items and rows), has overridden new/delete operators which use own Allocator object to allocate/deallocate memory on object create. The allocator has 2 modes: 1. Standard (by default) - the default application heap is used, as for any other Objects. 2. CustomHeap - the separate custom heap is used by this allocator. (See HeapCreate and other related Windows API functions) Allocator manage custom heap internally. When all objects deleted - allocator destroy heap (and create again for next allocations). This "Really" free all memory after all data removed and avoid Heap fragmentation problem. Also by default Allocator enable "Low-fragmentation Heap" (LFH) feature for custom heap. This optimize heap work in WinXP and later. But it does not works under debugger. 2. Batch Allocation. If we need to allocate many objects of the same type (size) it is more effective to allocate memory not for each object separately, but for some amount of such objects at one time (by batch). Batch Allocation implemented over Custom heap. This means that it can alloc batches in the standard heap as far as in the custom heap. When you call "new" for some batch allocable class, Batch Allocation mechanism allocate block for 1024 objects in the heap, return pointer for one object and add other 1023 to "Free List". For feature allocations objects from this "Free List" will be returned instead of new allocation in the heap. When free list will be empty - new batch block will be allocated and added to "Free List". When such object deleted (operator delete called) - it is added to "Free List" too (and will be used again for future allocations). This is increase allocation/deallocation speed and allow to avoid heap fragmentation. Batch Allocation manage list of batch blocks and list of free objects in each block. When all objects from some batch block is in free list - such block deleted automatically. FreeExtraData() method allow to delete these batch blocks from memory (from heap). This means that you have to call FreeExtraData after Remove All records and rows to really free memory. But if you plan to add some data again you should not do this. In this case you may call FreeExtraData after add new records and populate. -- WBR, Serge |
Posted By: ABuenger
Date Posted: 21 September 2007 at 6:22am
CString in MFC 6.0 uses CFixedAlloc for memory allocation which, as Serge said, keeps a list of all allocated memory for reusage in the release build. So it's actually not a leak but a feature. ------------- Codejock support |
sserge wrote:Posted By: mdoubson
Date Posted: 15 June 2009 at 4:23pm
|
I had a confirmation from already closed Issue:
Hi, No more leaks in 13.1 Beta. Thanks! But: Is it my feeling that the Report still uses quite a bit of memory (1Kb per row) ------------- Mark Doubson, Ph.D. |