Description: If your report(s) display large amounts of data, it may take a long time for the data to be retrieved from the database.

Optimization: With large amounts of database server data you need to retrieve the smallest usable set of data to reduce network traffic, use resources effectively and to render reports quickly. This can be achieved by using selections applied to data at the report level vs. user selections applied at the database. Selections applied at the database level are effective when the data does not need to be re-queried. This can be effective when only a narrow range of data is required. Additional trips to the database for different views of the same data increase the network traffic cost and the time needed to render the report. When user selections are applied at the report level the data is cached in-memory. This can be effective when different views of the same data are required and the data is not too large. A combination of these techniques may be the most appropriate solution. To filter data on database level and fetch only a subset of the data, review the Design Time Support for Parameterized Queries video.

Description: complicated binding expressions (especially with many report items) require time to be evaluated and they can also lead to slowness.

Optimization:  It is a good idea to replace these expressions with a user function. User functions are compiled code and would not be evaluated numerous times by our processing engine, like an expression would.

Description: You should avoid lots of nested reports and tables. SubReports require additional data filtering on the application side, and so do tables.

Optimization: The SubReport/table items are separate data regions. In the case when they are bound to the same data they will produce multiple unnecessary queries to the database. In this case, try simplifying the report by using textbox items directly in the master report (if applicable), rather than using SubReports and tables. You should also avoid using nested tables.

Description: The HTML and Excel rendering engines create a complex matrix taking into account every item's coordinates and size, and then create an HTML table with many table cells and rows, some of which are used merely as "spacers". This way an item's exact location and size are preserved, but at the cost of many calculations. When a report has tons of items that are not vertically and horizontally aligned, the resulting HTML table is gigantic.

Optimization: Align your items horizontally and vertically relative to each other and make sure that you have NO warning signs in design-time. While in TIFF and PDF formats the rendering locations and sizes do not relate to performance, in HTML and Excel this is critical. The more items are aligned horizontally and vertically, the less dummy spacer rows and cells will be created by the HTML and Excel rendering engine;

Description: Report items are first bound to data and then are rendered. If there are many report items on the report, its generation may take a while.

Optimization: Move the separate logical parts of your report into SubReports, and then combine them in one main report. Each SubReport will be rendered separately, which in turn will decrease the matrix complexity. Try not to put many report items into a single DetailSection, rather logically divide the report into parts and place them in separate SubReports. In this manner you will also be able to "assemble" many different kinds of reports later on, once you have created the "building blocks", i.e. the SubReports.

Description: The Chart item does not use the reporting data engine, but its own. As a result showing many charts involves extra data processing. Telerik is working on optimizing this behavior.

Optimization: Avoid using the IntelligentLabels property. If possible, minimize the amount of charts that you have to display. Usually charts are used for summary and group information, so natural place for its use is in the Group section, i.e. escape using the charts in the Detail section. If you are trying to mimic an existing application/page layout in a report, the chances are that the chart image has already been generated by the application. If so, simply reuse the already created chart image  and display it through the PictureBox report item. To do this, save the chart image to a stream, and feed this stream to the PictureBox Image property. For more information, review this article: Use asp:chart in Telerik Reports.

The CPU power and amount of memory have direct impact on the rendering performance. Obviously, the faster the hardware, the better.  For data- and layout-intensive reports, we would suggest a minimum of a dual core processor with at least 2 GB of RAM. Network traffic bandwidth also impacts performance.

Avoid using the ChildElements.Find method to loop through the report hierarchy – this method is time and memory consuming, and should be avoided in data- and layout-intensive reports. Telerik Reporting offers a reference to the items in the report, so using ChildElements.Find to locate items is not necessary. For example, instead of using: TelItem = Report.ChildElements.Find("txtQuotefor", True) you can directly refer to the appropriate field and save all the time taken in searching: TelItem = Me.txtQuotefor

If your case is not listed above, or you have tried all suggestions, but experience slow rendering, please open a new support ticket and send us the following so that we can investigate your case and check what is causing your troubles:

1. Detailed information about your report(s) and environment, i.e.
2. Your archived report files
3. The data source you're binding to