In this article we will go ahead and summarize the most important performance info we already have in our documentation resources. Optimization Tips series in the blogs:
server-side: The grid itself cannot cause server-side performance problems related to controls creations and/or render. There might be some possible problems with controls inside grid templates.
data-binding: The .NET 2.0 version of the grid is optimized to handle up to 1 000 000 records without major performance problems. Server-side paging will increase performance dramatically. Example: http://demos.telerik.com/aspnet-ajax/Grid/Examples/Programming/CustomPaging/DefaultCS.aspx .NET 3.5 version can handle millions of records and will apply paging, sorting and filtering directly on the data-base server (LinqDataSource) codeless: http://blogs.telerik.com/vladimirenchev/Posts/08-03-10/How_fast_is_your_ASP_NET_DataGrid.aspx?ReturnURL=%2fvladimirenchev%2fposts.aspx%3fYear%3d2008%26Month%3d3 Client-side data-binding approach is also very fast + you will get pure JSON transfer between client and server: http://blogs.telerik.com/VladimirEnchev/Posts/08-05-23/SQL_Server_sorting_paging_and_filtering_with_RadGrid_client-side_data-binding_to_WebService.aspx?ReturnURL=%2fVladimirEnchev%2fPosts.aspx
ViewState size: Some of the grid operations can work with completely turned off ViewState. Example: http://demos.telerik.com/aspnet-ajax/Grid/Examples/Programming/ViewState/DefaultCS.aspx. In client-side data-binding scenarios you do not need the ViewState also: Example: http://demos.telerik.com/aspnet-ajax/grid/examples/client/databinding/defaultcs.aspx.
HTML output size: RadGrid output is the smallest on the market however may depend on selected grid features, number of items per page and templates. Example: http://demos.telerik.com/aspnet-ajax/Grid/Examples/GeneralFeatures/Migration/DefaultCS.aspx.
Number of requests: Most of the grid images come from the grid CSS sprite which minimizes number of requests to the server for resources. Can be minimized with RadScriptManager and RadStyleSheetManager.
Some optimization features introduced in the ASP.NET AJAX version are:
semantic rendering to reduce HTML markup
certain editor scripts are loaded only if needed, reducing total script sent to client
use of optimized code relying on the common Prometheus framework
lazy initialization and loading for any client-side feature not immediately used.
Nonetheless, there are two scenarios where performance can degrade:
Having many editors on the page(10, 20 or even 30. More common in MOSS scenarios). RadEditor for ASP.NET AJAX initializes about 3-4 times faster than the Classic version on the client side. Nonetheless, having 30 instances of the editor is bound to cause a delay. However, this delay can be greatly reduced and brought to almost nothing – by setting a ToolProviderID (so that many editors share the same toolbar and no additional markup is sent on client), as well as set the ToolbarMode property – non default toolbars use lazy initialization and are initialized not when the page loads, but when an editor is first used (e.g. the user clicks in the content area). The following example demonstrates these two features: http://demos.telerik.com/aspnet-ajax/Editor/Examples/ToolProvider/DefaultCS.
Loading too much content into the editor (100K and more). This is done very rarely, but sometimes we get contacted about slow performance of the editor. Problem is not addressable – it is inherent. When having to deal with so much content, the browser eats lots of memory to provide for storing the editor states needed by the Undo/Redo, the Undo/Redo itself starts executing slowly due to the huge content.
The biggest challenge here is to deliver acceptable performance when dealing with lots of nodes (hundreds and thousands). To do so RadTreeView supports:
HTML markupRadTreeView renders the least amount of HTML needed to implement the features. However, the HTML size grows up dramatically when RadTreeView contains a few thousand of nodes. This issue cannot be easily tackled - even rendering a few thousand strings will generate lots of output. That’s where load on demand comes into play.
Load on demandThe idea is simple - render that HTML only when needed. RadTreeView supports three different types of load on demand:
Client-side (via ASP.NET Callbacks). This is technique is easier for the developer to implement however may not be a top performer because the whole ViewState is submitted on every request.
Server-side (regular postbacks which can be ajaxified) Worst performance. Mostly added for backwards compatibility. Full page update can be avoided by wrapping the treeview inside update panel.
Web-services Web services provide best performance because they completely skip the heavy page lifecycle and don’t require sending huge ViewState strings. All types of load on demand keep logging the nodes created on demand. This however introduces a delay after numerous loads on demand requests since the log grows bigger. This is required by customers who want the nodes created on demand do be persisted after postback (or those nodes need to fire server-side events - click, drag and drop etc). This means that after some time all load on demand schemes (without server-side) get slower. Fortunately, there is a property PersistLoadOnDemandNodes which controls this behavior.
Again performance might degrade with lots of items and lots of combobox instances. This is addressed by using load on demand.
HTML markupRadComboBox renders unordered list for its dropdown which is quite light. This is the least amount of html required to render the dropdown.
Load on demandRadComboBox supports two types of load on demand (with caching of items):
It supports web service load on demand and lazy initialization (transparent for the user). RadMenu can seamlessly work with disabled ViewState.
RadDatePicker, RadDateTimePicker and RadTimePicker
Performance problems can be caused by using the picker in list controls. An example how to optimize this can be found here:
RadDateInput, RadNumericInput, RadMaskedTextBox and RadTextBox
Performance problems can be caused by using these controls in templates of list controls. A better idea is to create an outside edit form similar to this example:
RadTooltip RadTooltipManager are quite lightweight and generally there are no problems with performance. However, in templated scenarios the number of tooltip controls on the page can easily go out of hand. We have seen scenarios involving 1000+ tooltips on a single page. Since each of them needs to be initialized on client page load, the system takes a lot of time to do it, especially If
<compilation debug=true>. In such scenarios there is a better approach to the tooltips – and that is using a couple of lines of client-side code that will create a tooltip only when the user needs to see it. The following demo demonstrates this approach: http://demos.telerik.com/aspnet-ajax/ToolTip/Examples/RadToolTipManagerClientAPI/DefaultCS.aspx
A brand new mechanism for updating RadSplitter's child controls was introduced that is many times faster than the old one which traversed every single HTML element to test whether it is a Telerik control.
Data-binding: We recommend that customers bind RadScheduler only with appointments that are visible in the currently selected view. This makes performance a non-issue, as the views are limited to a few thousand appointments at maximum.
ViewState size: RadScheduler can work entirely without ViewState, if necessary. Customers pay the usual penalty of having to bind the data on each page load.
Number of requests: On-demand loading of scripts generates a few additional requests. Other than that, the number is rather low, as skins contain very little number of images. Using RadScriptManager and RadStyleSheetManager reduces the number even further.
The RadHtmlChart renders SVG in modern browsers and VML in older browsers that do not support SVG (i.e., IE8 and below), that are essentially forms of an XML document. This means that the chart's image will be created by numerous elements (i.e., XML nodes) and rendering them may take some time for the browser. In scenarios where the chart has many components like series items, x/y axes labels, major and/or minor grid lines (i.e., path and text elements for the rendering) and the animation is enabled (it is enabled by default), the overall rendering time may be increased because the browser will have to draw too many elements and animate them.
The performance also greatly depends on the performance of the machine and the browser. Slower browsers like IE7 and IE8, especially when used on slower machines, may not meet all your needs. This can be aggravated by the presence of many charts on the page and the page's load time will increase proportionately.
The way to improve the rendering speed of the chart is to remove the most numerous elements that can slow down the browser. There are several things you could do in order to speed up the RadHtmlChart's client-side rendering:
Disable the chart's animation by setting the Transitions property to false. By doing so, the browser will not have to animate the thousands of XML nodes in the chart image.
Hide the MinorGridLines and/or MajorGridLines of the X and/or Y axes by setting the [YAxis/XAxis].[MinorGridLines/MajorGridLines].Visible property to false.
Hide the series' labels by setting the [Series Object].LabelsAppearance.Visible property to false. When there are thousand of items the labels would be hardly readable and are likely to only create visual clutter.
Hide the X and/or Y axes' labels by setting the [YAxis/XAxis].LabelsAppearance.Visible property to false. You can also set a higher value for the axes labels step through the [YAxis/XAxis].LabelsAppearance.Step property.
You can see an example of an optimized chart configuration in RadHtmlChart Performance Optimizations help article.
RadScriptManager and RadStyleSheetManager
When loading a page with several controls on it, the number of these files can become very large, often resulting in a reduced page load time and increased traffic. The reason for this problem is that browsers make separate requests to the server for each of these resources.
Usually this problem is overcome by disabling the automatic script and stylesheet serving the controls, combining them into a smaller set of files and manually registering the links to these files in the page.
This approach is not the best for a number of reasons:- you must extract the files from the assembly for each control release;- files become too large to be maintainable (or you have to write a script to merge the source files);- the number of the merged files you need to maintain can become very large depending on the control sets you have on different pages;