I am trying to make a large grid perform adequately while scrolling. The grid is 40 columns with a page size of 50. Thirty-five of the columns are always editable.
Is there documentation on the understood limits on the performance of the kendo grid? I do not want to waste time trying to get the performance up if my scenario is significantly outside of the guidelines.
While profiling the grid, I also noticed that the header row is being rerendered even though none of the props have changed. Same goes for the filter row. Is this an issue in KendoReact or have I screwed something up in my headerCellRender function?
7 Answers, 1 is accepted
The Grid will perform well with 40 columns and page size of 50. If any performance issues are observed, reducing the pageSize will prove helpful.
Also, we are planning the make virtualization of the columns as well which will be very helpful in cases like this when the columns number is large.
As for the header and filter rows, I can assume that the re-render occurs because a key attribute is not added to the custom cells. The keys are what React uses to keep track of the changes and re-render only when needed:
Regards,
Stefan
Progress Telerik
Rank 1
Thanks for the suggestions.
My element matches the picture you have attached so I do not think the key is missing. I think I will run through the demos and see if they have similar problems.
Thank you for sending the profiler data.
I made tests and everything was rendering fast. I noticed that in the provided screenshot one GridCell was render slowly around 17ms. Could you please advise which is this cell? Does it have something more specific to render or?
Regards,
Stefan
Progress Telerik
Rank 1
It is not consistent. Every time I profile, different cells take longer. Sometimes none of them are outliers.
There are only two states the header render takes into account: The field is checkbox -> use a custom header with click handling. Otherwise -> use the passed in header.
I cannot think of why only one column would be the performance bottleneck. Some of it may be the development tools injecting additional overhead, etc.
I did some profiling of the virtual scrolling demo. It renders the header every time. Am I right in thinking this might be a simple way to improve grid performance?
The Grid have linear performance per cells. So any performance limitation would be the cells inside it and the time React spends to render them.
Currently the horizontal scrolling causes re-renders, and this will be changed in the next major version, where we will put the header inside the same table as the body, and remove the sync-ups between the two tables that are now rendered per each grid. The new rendering will not support static headers in IE, and it is expected to be available in next release about 3 months from now.
Regards,
Vasil
Progress Telerik
Rank 1
Sounds good.
Please be aware that the virtual scrolling demo is for _vertical_ scrolling, not horizontal.
I was able to get performance to an acceptable if uncomfortable level. Given that performance scales linearly, are their standards for how many cells are the limit for a bog standard grid? How about if we add editing to all the grids? While I could collect this data myself, I assume someone on the Telerik React team has already identified the boundaries.
While we test with big grids on regular basis, it would be very hard to give some kind of boundaries. The acceptance level of frames per second would depend on multiple factors:
Browser - generally faster in Edge and Chrome, and slower in Firefox and IE
Hardware - CPU, GPU, etc. And even monitor resolution and how big the browser window is.
OS - Mac and Windows handles scroll a bit different.
Desktop, Tablet, or Cellphone - huge difference in their performance.
Is the machine in idle or other things are happening at the same time.
It would be best if you consider the hardware of your end users, and prepare the app that is suitable for them.
Regards,
Vasil
Progress Telerik