Article relates to
Telerik Reporting, all versions
June 12 , 2013
Last modified by
The processing time (as well as consumed memory) depends heavily on the
Basically, the more complex the report, the more time it will take to get it
rendered. Let’s look at each of the above and how to improve performance:
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
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
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
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
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
Optimization: In Q1 2013 we have introduced the Graph item. The new item utilizes the optimized reporting data engine. Thus we highly recommend it over the obsolete Chart item.
Still if you have to use the obsolete Chart item, 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
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
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
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:
Copyright © 2002-2014 Telerik. All rights reserved.
Powered by Telerik Sitefinity CMS