Report::ResetContent() performance.....

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   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?

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
ddlittle Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 19 February 2004 Location: United States Status: Offline Points: 132	Post Options Post Reply Quote ddlittle Report Post Thanks(0) Quote Reply Topic: Report::ResetContent() performance..... 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?

Smucker Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 02 February 2008 Status: Offline Points: 156	Post Options Post Reply Quote Smucker Report Post Thanks(0) Quote Reply 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.

Marco1 Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 16 January 2004 Location: Germany Status: Offline Points: 251	Post Options Post Reply Quote Marco1 Report Post Thanks(0) Quote Reply 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

Marco1 Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 16 January 2004 Location: Germany Status: Offline Points: 251	Post Options Post Reply Quote Marco1 Report Post Thanks(0) Quote Reply 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.