Hi
We have integrated KendoUI Grid in our project and it went fine. But until recently we used it for a particularly complicated page, the performance become very slow and unacceptable when browse in IE. We tested IE8,9,11, all perform poorly. sometimes we even get the "stop script" error in IE.
Is there any suggestion? or solutions?
Here's some details:
- Kendo UI v2014.3.1119
- 33 columns
- 250+ rows
- 3 level grouping
- some column is cell editable
- no paging is allowed
- use groupHeaderTemplate and groupFooterTemplate to display subtotal
- 2 columns freeze
3 Answers, 1 is accepted
Based on the provided information it seems that the main reason for the slowdown is the combination of frozen columns and a large number of rows.
In order to fulfill this configuration, the Grid renders two tables and synchronizes their row heights and scroll positions.The time needed for this scales linearly with the number of rows.
In order to improve the performance in this case I recommend you either:
a) Use virtual scrolling to reduce the actual number of rendered rows: http://demos.telerik.com/kendo-ui/grid/virtualization-remote-data
b) Disable frozen columns
Regards,
Pavlina
Telerik
Hi Yunan. I just want to add that, if you use "virtual scrolling", your grouping will not work as expected, if you set virtual scrolling you must use paging, and your "grouping" will only be applied on the "current" page, so your group totals will be inexact, and you will not see groups from other pages! That solution is almost unusable (enable grouping + enable virtual scroll)
We also noticed some performance issues in IE also (the latest IE in Win10), cpu goes up to 20% on a I7 when scrolling! I didn't compare with oldest version of kendo to see if there's a difference... We use frozen, grouping, ... looks like we're using the grid the same way!
In general the DOM operations are relatively slower in IE than in other modern browsers, because the IE browser cannot handle large amounts of HTML. Therefore to improve the performance we would recommend decreasing the pageSize, so less DOM elements are rendered or use virtual scrolling.
Regards,
Pavlina
Telerik
Have you determined what exactly is slow - the data loading or the rendering of data rows? In case of large data it is recommended to use serverPaging. In this way the Grid will display and load the data in a small chunks which will significantly boost the performance.
If this is not an option for you we will need a runnable example in order to inspect further and provide additional advice how to improve the performance.
Regards,
Pavlina
Telerik
My sample data is around 1400 records that will group into 40 categories. There are 9 status options that I want to aggregate and show the count of items with each status on the group header.
I've found that using grouping is noticeably slower than without grouping, and shouldn't be used with paging at all, but it is STILL worth the slightly extra wait time to be able to present my data as grouped. I don't know how much multiple grouping would slow as I don't need more than a single grouping level.
BUT
When I add the extra work of doing nine aggregate values for each of the 40 groups, it slows down the page load by a LOT, making for 20-80 second loading delay, which I consider to be unusable.
So my solution is to query once for the grouped data, which SQL presents fairly quickly, and separately query to retrieve only the values for the aggregates (calculated SQL side based on the data) and then pass the correct set of aggregates to each ClientGroupHeaderTemplate using a javascript function.
.ClientGroupHeaderTemplate("#=goBuildHeader(value)#")
Hi Darron,
Thank you for the provided extensive information on the case that you are facing. In general, when the grid is configured for client-side operations, all of the calculations are performed on the client. Therefore, having complex calculations might have a negative impact on the performance of the application.
In such cases, it is recommended to make use of all of the server operations. All of the complex calculations would be done on the server-side and the grid would simply display them.
Enabling the options above would eliminate the need for custom ajax requests.
Best regards,
Tsvetomir
Progress Telerik