Optimization can be crucial for large reports (i.e. over 100 pages). Here is some information which will help you to achieve the best possible results for such reports. To optimize ActiveReports for the web, please refer to the memory considerations section.
Memory Considerations
- Images Limit the use of large images when exporting to RTF and TIFF formats. Note that even one image uses a lot of memory if it's repeated on every page of a very long report exported to TIFF or RTF. If you are not exporting, or if you are exporting to Excel, PDF, or HTML, repeated images are stored only once to save memory, but the comparison necessary to detect duplicate images slows the processing time for the report.
- Subreports Limit the use of subreports in repeating sections because each subreport instance consumes memory. For example, consider that a subreport in the Detail section of a report in which the Detail section is repeated 2,000 times will have 2,000 instances of the subreport. Nested subreports will compound the number of instances. If you need to use subreports in repeating sections, instantiate them in the ReportStart event instead of the Format event of the repeating section so that they will be instantiated only once and use less memory.
- CacheToDisk Set the CacheToDisk property of the Document object to True. Although it will slow down the processing time, this will cause the document to be cached to disk instead of loading the whole report in memory. The PDF export will also detect this setting and use the cached report to export. Please note that only the PDF export is affected by the CacheToDisk Property; other exports may run out of memory with very large reports. Also note that CacheToDisk uses IsolatedStorage to store a page’s canvasItems to disk. To use CacheToDisk you must have IsolatedStorageFilePermission.
- Summaries Placing summaries (primarily page count and report totals) in header sections will have an adverse effect on memory as well as rendering speed with large reports using the CacheToDisk property. Since the rendering of the header is delayed until ActiveReports determines the total or page count of the following sections, CacheToDisk is unable to perform any optimization. The greater the number of affected sections, the longer rendering is delayed and the less optimization CacheToDisk will offer. Therefore, a group total in a group header section does not affect performance and memory as much as a report total in the report header.
- Releasing Reports To properly release a report instance from memory, take these steps in the following order:
- Call the Dispose() method of the Document object
- Call the Dispose() method of the Report object
- Set the Report object to null
The following code uses the above steps to release a report.
To write the code in Visual Basic.NET
| Visual Basic.NET code. |  Copy Code |
|---|---|
rpt.Document.Dispose() rpt.Dispose() rpt = Nothing | |
| C# code. | Copy Code |
|---|---|
rpt.Document.Dispose(); rpt.Dispose(); rpt = null; | |
Speed Considerations
- Images An image repeated on every page of a very long report is stored only once to improve memory, but the comparison necessary to detect duplicate images slows performance. This is not only the case with the report document itself, but also with the Excel, PDF, and HTML exports as they perform their own comparisons.
- Summaries Placing summaries (primarily page count and report totals) in header sections will slow report processing. ActiveReports must determine the total or page count of the following sections before it can render the header section. The greater the number of affected sections, the longer rendering is delayed. Therefore, a group total in a group header section does not affect performance and memory as much as a report total in the report header.
- CacheToDisk Be sure that the CacheToDisk property of the Document object is not set to True. Setting it to True increases the amount of time the report takes to load, and should only be used with very large reports that use a lot of memory. If this is used with smaller reports of less than 100 pages, it may actually cause more memory to be used.
- Stored Procedures Using stored procedures instead of SELECT statements speeds up the processing time of a report, as it reduces the number of records handled by ActiveReports. Using SELECT * statements is not recommended unless you are actually using all of the data returned by such a statement. Consult your database administrator for other ways to speed up data retrieval, such as indexing tables.