Hello all
I've been diagnosing a problem with a grid control being slow to respond to user input for a sister company. This is using the trial version of 2012 Q1 (this sister company does have a license, but I don't have access so installed the trial version).
Row selection in a grid with just over a 1000 rows in now quicker, but it still too laggy (taking about 0.2 seconds for selection to change). This software generates grids on the fly from user designs in the database, and the grids can be quite complex with check boxes and drop down lists in the table elements, which if there are a number of controls on there seems to slow everything down to a crawl (which to be fair I'd sort of expect, with a DOM with 20,000 drop down lists in it).
I was just wondering if there is a suggested maximum number of rows to populate in a grid? Is paging always recommended to make the control act in a controllable manner disregarding the number of rows it has to display?
Cheers.
Ian C
2 Answers, 1 is accepted
0
Hello Ian C,
There could be no suggested maximum number of grid items because it is not only the item number that may hit performance. As you have discovered, you may have relatively less number of items (1000 for example), but if the grid contains thousands of column and most important thousands of other controls, then a performance hit may be observed.
Generally speaking, paging is always a good idea when it comes to performance. Of course it is not the only technique you can utilize. I would suggest that you review the resources bellow that provide some more information on the matter (the second link is part of a larger "performance" section which describes some more scenarios that might be of your interest):
Optimizing output, page load time and the overall performance of RadControls for ASP.NET AJAX
Client/server grid performance optimizations
I hope this helps.
Regards,
Martin
the Telerik team
There could be no suggested maximum number of grid items because it is not only the item number that may hit performance. As you have discovered, you may have relatively less number of items (1000 for example), but if the grid contains thousands of column and most important thousands of other controls, then a performance hit may be observed.
Generally speaking, paging is always a good idea when it comes to performance. Of course it is not the only technique you can utilize. I would suggest that you review the resources bellow that provide some more information on the matter (the second link is part of a larger "performance" section which describes some more scenarios that might be of your interest):
Optimizing output, page load time and the overall performance of RadControls for ASP.NET AJAX
Client/server grid performance optimizations
I hope this helps.
Regards,
Martin
the Telerik team
If you want to get updates on new releases, tips and tricks and sneak peeks at our product labs directly from the developers working on the RadControls for ASP.NET AJAX, subscribe to their blog feed now.
0
Ian
Top achievements
Rank 1
Rank 1
answered on 18 Jun 2012, 08:21 AM
Thanks for the pointers Martin.
I was assuming the performance was a function of the columns and the rows with my own tinkering.
We've decided to simply enable paging. Some of the performance fixes aren't really suitable to our software as the page objects are created on the fly from an existing interface the existing native WPF application uses to a non-.NET service, and the existing web interface implementation recreates page objects when the user posts back a change to the server (which can be pretty much on doing anything due to server-side workflow) and the objects get recreated. So it's not a 'classic' ASP.NET application. Therefore I'll have to store the current page settings and restore them when the grid is recreated.
I realise this is a sub-optimal solutuion, but a quick fix is requried for the time-being so that acceptence and the like can progress, and the server responses and reconstruction are quick enough to not make the interface laggy, excepting this problem with large grids. I'm just looking at this for someone else and are more used to the Silverlight controls, and wanted to make sure I wasn't missing something obvious to make the grids fly.
Thanks for the pointers again. Cheers.
Ian C
I was assuming the performance was a function of the columns and the rows with my own tinkering.
We've decided to simply enable paging. Some of the performance fixes aren't really suitable to our software as the page objects are created on the fly from an existing interface the existing native WPF application uses to a non-.NET service, and the existing web interface implementation recreates page objects when the user posts back a change to the server (which can be pretty much on doing anything due to server-side workflow) and the objects get recreated. So it's not a 'classic' ASP.NET application. Therefore I'll have to store the current page settings and restore them when the grid is recreated.
I realise this is a sub-optimal solutuion, but a quick fix is requried for the time-being so that acceptence and the like can progress, and the server responses and reconstruction are quick enough to not make the interface laggy, excepting this problem with large grids. I'm just looking at this for someone else and are more used to the Silverlight controls, and wanted to make sure I wasn't missing something obvious to make the grids fly.
Thanks for the pointers again. Cheers.
Ian C