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 slows down the processing time, this allows the document to be cached to disk instead of loading the whole report in memory. The PDF export also detects this setting and exports the cached report. Please note that only the PDF export is affected by the CacheToDisk property; other exports may run out of memory with very large reports. By default, CacheToDisk uses IsolatedStorage, which requires IsolatedStorageFilePermission.
It is recommended that you use the CacheToDiskLocation property to specify the physical path instead of using isolated storage so that you do not run into the size limit.
- Summary: 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.
Speed Considerations
- Image: 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.
- SELECT *：Using the SELECT * statement is only recommended when you actually want to use all of the data returned by this statement. Contact your database administrator for other methods to speed up your queries.
Printing Considerations
- Virtual Printer：We recommend use of virtual printer in case report generate environment differs from the environment in which the report is viewed or printed like in the case of Web applications.
- Line：Please be careful as Line control has been used to draw borders within a report. An issue has been observed that spool size is increased (when comparing with Solid) during printing in case LineStyle property is set to an any value e.g. Dash or Dot etc. other than Solid that is the default value. As a result, time is taken for spooling by the report thus hindering the performance while printing. Same issue is observed when rendering a line using GDI+ in PrintDocument of .NET Framework.