I am looking for new ways to improve the load performance of the RadGridView control.
I already had a look at the tips from your site, and have followed many of them while others do not apply as we have some special requirements which I could not achieve using your default styles.
I found that reducing the number of FrameworkElements in the Grid greatly improves the loading performance. Using Snoop, I found that we had nearly 20000(!) FrameworkElements on a full-page GridView (with row-virtualization enabled, as we found that column-virtualization severely reduced the horizontal scrolling performance). After doing some optimizations, I was able to reduce the number of elements to now 5200, reducing the loading time from more than 5 seconds to 1.5 seconds (on a fast development PC - it could still be much slower on a user PC).
One big impact factor is the GridViewCell template. If you have a look at the template (in our case the VisualStudio2013 version), it has 174 lines of code and ~12 FrameworkElements! By creating my own template (specifically for WPF, using triggers), I was able to reduce it to 32 lines of code and 2 FrameworkElements (1 border for cell separation + 1 ContentPresenter), maintaining the same look as before (maybe not every single behavior is reproduced, but the ones that we use). This single optimization leads to a reduction of loading time by ~1.4 seconds!
Now I would like to further reduce the number of elements. One Idea was to merge the GridViewCell with the border and the ContentPresenter - having 1 element instead of 3. The next step would be to implement some kind of "cell renderer" to draw simple cell templates (like the TextBlock) in the OnRender event, saving one (or more) further elements per cell. To achieve this, I have to derive from GridViewCell(Base).
However, there is one problem: While the CreateItem method in the RadGridView is protected (so I could create a derived GridViewRow), the CreateItem method in the GridViewRow is internal, effectively stopping me from creating my own implementation of GridViewCell. I am wondering why it was decided to do it this way? I see that you are accessing the method from outside the row, so protected would not be an option. But what about "protected internal"? Changing it to this should not break an usage - but allows to greatly improve usability of the class.
Alex
I already had a look at the tips from your site, and have followed many of them while others do not apply as we have some special requirements which I could not achieve using your default styles.
I found that reducing the number of FrameworkElements in the Grid greatly improves the loading performance. Using Snoop, I found that we had nearly 20000(!) FrameworkElements on a full-page GridView (with row-virtualization enabled, as we found that column-virtualization severely reduced the horizontal scrolling performance). After doing some optimizations, I was able to reduce the number of elements to now 5200, reducing the loading time from more than 5 seconds to 1.5 seconds (on a fast development PC - it could still be much slower on a user PC).
One big impact factor is the GridViewCell template. If you have a look at the template (in our case the VisualStudio2013 version), it has 174 lines of code and ~12 FrameworkElements! By creating my own template (specifically for WPF, using triggers), I was able to reduce it to 32 lines of code and 2 FrameworkElements (1 border for cell separation + 1 ContentPresenter), maintaining the same look as before (maybe not every single behavior is reproduced, but the ones that we use). This single optimization leads to a reduction of loading time by ~1.4 seconds!
Now I would like to further reduce the number of elements. One Idea was to merge the GridViewCell with the border and the ContentPresenter - having 1 element instead of 3. The next step would be to implement some kind of "cell renderer" to draw simple cell templates (like the TextBlock) in the OnRender event, saving one (or more) further elements per cell. To achieve this, I have to derive from GridViewCell(Base).
However, there is one problem: While the CreateItem method in the RadGridView is protected (so I could create a derived GridViewRow), the CreateItem method in the GridViewRow is internal, effectively stopping me from creating my own implementation of GridViewCell. I am wondering why it was decided to do it this way? I see that you are accessing the method from outside the row, so protected would not be an option. But what about "protected internal"? Changing it to this should not break an usage - but allows to greatly improve usability of the class.
Alex
3 Answers, 1 is accepted
0
Hello Alex,
Pelase excuse us for the delayed reply. Can you please confirm whether you are using StyleManager, or the theming mechanism that is based on implicit styles? Generally, the latter one is significantly faster in terms of load time. Additionally, you can cosider using the lightweight templates that we are shipping, if you have not tested them already.
As for your specific request regarding the CreateItem method of GridViewRow, you are right that this won't be a breaking change and it seems logical that a GridViewRow's children (cells) should be open for extension. However, we would want to take some time to test it before taking any further action.
As a side note, please be advised that any drastic customizations that interfere with the core logic of GridViewCell may be harmful for the working behavior of RadGridView.
Regards,
Ivan Ivanov
Telerik
Pelase excuse us for the delayed reply. Can you please confirm whether you are using StyleManager, or the theming mechanism that is based on implicit styles? Generally, the latter one is significantly faster in terms of load time. Additionally, you can cosider using the lightweight templates that we are shipping, if you have not tested them already.
As for your specific request regarding the CreateItem method of GridViewRow, you are right that this won't be a breaking change and it seems logical that a GridViewRow's children (cells) should be open for extension. However, we would want to take some time to test it before taking any further action.
As a side note, please be advised that any drastic customizations that interfere with the core logic of GridViewCell may be harmful for the working behavior of RadGridView.
Regards,
Ivan Ivanov
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.
0
Alexander
Top achievements
Rank 1
Rank 1
answered on 17 Mar 2015, 08:58 AM
Hi Ivan,
thanks for your answer. We are using the implicit styles from the Telerik.Windows.Themes.VisualStudio2013.dll (by adding the resource dictionaries to the app.xaml resources). However, as I said, the default styles were to slow for us - and it seems that one main reason is the large number of FrameworkElements. I am not sure what exactly are the lightweight templates you mentioned. Are these different to the implicit styles?
My final goal would be be to reduce the number of FrameworkElements to a single element per cell, where the contents are drawn in the OnRender method, hoping that this will improve the performance to an acceptable level. In the mean time, I tested our application on a low-end pc (atom processor, but a possible use case...), but the Grid still takes ~6 seconds to load, and a similar amount of time for grouping/sorting (with the original templates, this were ~15 seconds). This is way too slow...
Alex
thanks for your answer. We are using the implicit styles from the Telerik.Windows.Themes.VisualStudio2013.dll (by adding the resource dictionaries to the app.xaml resources). However, as I said, the default styles were to slow for us - and it seems that one main reason is the large number of FrameworkElements. I am not sure what exactly are the lightweight templates you mentioned. Are these different to the implicit styles?
My final goal would be be to reduce the number of FrameworkElements to a single element per cell, where the contents are drawn in the OnRender method, hoping that this will improve the performance to an acceptable level. In the mean time, I tested our application on a low-end pc (atom processor, but a possible use case...), but the Grid still takes ~6 seconds to load, and a similar amount of time for grouping/sorting (with the original templates, this were ~15 seconds). This is way too slow...
Alex
0
Accepted
Hi,
Lightweight templates are an alternative set of ControlTemplates for GridViewRow and GridViewCell. They have simpler structure than the standard ones, aiming better performance. Here is an article about this feature.
As for your original inquiry about exposing GridViewRow's CreateItem method, we will write back to you as soon as we have carried out the needed tests.
Regards,
Ivan Ivanov
Telerik
Lightweight templates are an alternative set of ControlTemplates for GridViewRow and GridViewCell. They have simpler structure than the standard ones, aiming better performance. Here is an article about this feature.
As for your original inquiry about exposing GridViewRow's CreateItem method, we will write back to you as soon as we have carried out the needed tests.
Regards,
Ivan Ivanov
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.