I am very sorry to hear about your frustration with performance while using Telerik RadControls.
We have a lot of optimization techniques for RadControls and I am sure some of them will be of great help for your project. You have not specified which controls (and which version) from the suite you are using so I will just go ahead and summarize the most important performance info we already have in our documentation resources. If the info below does not help, please do not hesitate to provide some further details and send us a sample of your project where you experience the performance issues and we will gladly look into it. While having a GoToMeeting session is definitely an option, our experience shows that improvements are more efficient and much quicker to implement if we review some of your source code before that.
Optimization Tips series in the blogs:
Optimization Tips:The Rad Managers for ASP.NET AJAX
Optimization Tips: Testing Page Performance
Optimization Tips: Using RadAjaxManagerProxy Controls
Optimization Tips: Using HTTP Compression
Optimization Tips: Optimizing Custom Skins
- 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 100 000 records without major performance problems. Server-side paging will increase performance dramatically.
.NET 3.5 version can handle millions of records and will apply paging, sorting and filtering directly on the data-base server (LinqDataSource) codeless:
Client-side data-binding approach is also very fast + you will get pure JSON transfer between client and server:
- ViewState size: Some of the grid operations can work with completely turned off ViewState.
In client-side data-binding scenarios you do not need the ViewState also:
- 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.
- 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.
- Other: http://www.telerik.com/help/aspnet-ajax/grdviewstatereductiontechniques.html
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:
1. Having many editors on the page (10, 20 or even 30. More common in MOSS scenarios).
The Prometheus editor 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:
2. 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:
1. HTML markup
RadTreeView 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.
2. Load on demand
The idea is simple - render that HTML only when needed. RadTreeView supports three different types of load on demand:
a. 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.
b. 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 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.
3. Initialization of the client object
RadTreeView supports on demand initialization of nodes which are not visible (their parent nodes are collapsed). This is transparent to the user. However, invoking the client-side API (e.g. get_allNodes()) can force full client-side initialization which is a time consuming operation in case of a few hundred nodes. Also logging client side changes which need to be reflected on the server (checking a node, selecting a node) from the client-side API can be slow with lots of nodes.
A QSF example demonstrating web-service load on demand with disabled viewstate will demonstrate the top performance achievable with RadTreeView. Also the performance section of the help provides some further insights.
Again performance might degrade with lots of items and lots of combobox instances. This is addressed by using load on demand.
1. HTML markup
RadComboBox renders unordered list for its dropdown which is quite light. This is the least amount of html required to render the dropdown.
2. Load on demand
RadComboBox supports two types of load on demand (with caching of items):
b. Callbacks (ASP.NET 2.0 Callbacks)
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
Having lots of page views (inside RadMultiPage) can slow down switching between tabs. Also it generates lots of HTML (because of the controls contained in the pageviews). To tackle this problem we have an online example demonstrating how to load pageviews on demand via AJAX. The multipage also has a property “RenderSelectedPageOnly” which does exactly what it says. In this case switching to a new page view requires postback.
RadAjaxManager & RadAjaxPanel
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:
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 RadControl.
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 Telerik team
Check out Telerik Trainer
, the state of the art learning tool for Telerik products.