Report::ResetContent() performance.....
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=10285
Printed Date: 29 September 2024 at 5:31am
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com
Topic: Report::ResetContent() performance.....
Posted By: ddlittle
Subject: Report::ResetContent() performance.....
Date Posted: 17 April 2008 at 3:57pm
|
I have several reports that might have 100K lines in them (not at the same level, say 1000 lines, each with 100 children). Populating the lines is very fast, but if my user opens another model, I do a ResetContent() prior to re-populating and that can sometimes take 500 seconds or so - which is beyond most user's patience, they think the machine is dead...
I tried the example program "ReportCustomHeap" and noticed similar performance issues. When adding records, it's possible to pre-allocate memory, but removing them is apparently a one-at-a-time operation.
Anybody have any ideas?
|
Replies:
Posted By: Smucker
Date Posted: 20 April 2008 at 4:17am
|
If you're testing with a compiled debug version, the C/C++ runtime libraries take a lot longer to release memory, especially for 100K items (assuming these are allocated individually). The debug code scans each block (paging it in if necessary) to check for heap corruption, etc. For further speed, if you create your own heap HeapCreate(), and use HeapAlloc() to allocate only the report items, you can clear them all very quickly, by simply deleting and recreating the heap. This has a nice side effect of returning the memory to the system immediately, though some leak detectors may not recognize this and report all the items as leaked. Also, if your items are always allocated by a single thread, you can create the heap using HEAP_NO_SERIALIZE flag, reducing locking overhead and speeding allocations. |
Posted By: Marco1
Date Posted: 02 February 2011 at 2:38pm
|
Has anyone found a solution for this? I tested ResetContent (which is called during report destruction) with PerformanceTestDlg in the CJ Report sample. When I set the row count in the example to 10000 (instead of 1000) it takes about 15 seconds(!) on my notebook just for ResetContent - compiled as RELEASE version. I know that delete is a very expensive function, but 15s for 10k rows are not acceptable. Using virtual mode is not a good option due to sorting/grouping restrictions. ... and I already have the slight feeling that my customer won't accept that  ------------- Product: XTP 18.3.0 on VS 2017 Platform: VS 2017 / Windows 10 (64bit) |
Posted By: Marco1
Date Posted: 09 February 2011 at 5:30am
|
This weekend I investigated this case a little deeper. Long story short, it seems that string classes (esp. CString) are very slow in destruction (due to discrete delete). If 50000 CStrings need to be destructed, (mem management) requires significant time. A list full of ReportRecordItemNumbers only is fairly fast. In the moment I'm testing STL containers and own ReportRecordItems which contains only pointers to the STL stored strings to avoid CStings. Don't know yet, if that is sooo much better. Any suggestions are really appreciated. ------------- Product: XTP 18.3.0 on VS 2017 Platform: VS 2017 / Windows 10 (64bit) |