Hello there,
This topic isn't a question or looking for help, I just wanted to share my experience with one thing that costed me weeks of work and could've been avoided easly.
So, in my WPF application I have 1 quite big page - 12k+ lines of code behind + xaml. Having so big class in application causes, ofc, problems, but what I've had to deal with was memory leaks. Page, mentioned above, is an Order page, consists many elements and data, but what is important is 1 RadGridView - Order Lines GridView. Now, my client expects application to have various styles and colors, so I have few CellStyleSelectors and 1, simple, RowStyle:
<
Style
TargetType
=
"telerik:GridViewRow"
x:Key
=
"NormalStyle"
BasedOn
=
"{StaticResource GridViewRowStyle}"
>
<
Setter
Property
=
"Background"
Value
=
"{Binding Color}"
/>
<
Setter
Property
=
"Foreground"
Value
=
"Black"
/>
<
Setter
Property
=
"BorderThickness"
Value
=
"0 0 1 0"
/>
</
Style
>
It is used to get desired background color from database and set it to row. And here is where my problems have started.
If you don't set such style, color will be, naturally, bound to current application style (default - Office Black), but what will happen, when you declare, that you will provide hex color code and you don't?
I've had some misscomunication problems with my database dev, he had no idea, that he must to provide something in Color column (20-30% of returned rows were Null) and I wasn't aware of that.
And it is a HUGE problem problem for application. Now, I want to share some of my experiences with that:
- Rendering time:
Before I've realized that this is a problem, I've tested some scenarios. My approach was to remove everything unnecessary from Order page, which lead me to have only my RadGridView. I've done some testing for 330 records, and rendering time was around 1 minute (54s - 74s).
- Virtualization solution:
It is said in Telerik documentation, that Grid Virtualization is turned on and should be never turned off. Well, for this specific problem, turning it off increased first render of Page by 300%, but ALLOWED user to scroll through RadGridView. It was nearly impossible (in rational time) to scroll grid down from first item, to the last item. It is because every new visual element (row) needs to be rendered, and for this case, app was searching for correct color to set (unexpectly, it is very long process).
- Deferred Searching
Here is the issue simillar to virtualization problem - with
OrderLinesGrid.IsSearchingDeferred =
false
;
set, it was nearly impossible to filter Order Lines Grid, using built-in search panel.
- Check box column issues
The first place I've found problematic in the matter of performance, was mine checkbox column defined as below:
<
telerik:GridViewDataColumn.CellTemplate
>
<
DataTemplate
>
<
CheckBox
IsChecked
=
"{Binding CzyMagWyprz, Mode=TwoWay}"
HorizontalAlignment
=
"Center"
Checked
=
"ToggleButton_OnChecked"
Unchecked
=
"ToggleButton_OnChecked"
/>
</
DataTemplate
>
</
telerik:GridViewDataColumn.CellTemplate
>
Lets compare above 4 points with current state of my application (after fixing problem - correclty returning color):
- Rendering time:
For 330 positions and virtualization turned OFF, opening new page is ~ 30.98 s long. The same page with virtualization turned ON opens in... ~ 2,35 s - Virtualization solution:
Well, scrolling through 330 rows with some styling is a little too slow. I mean, it is not completly fluent (with virtualization turned on), but well, opening time makes it negligible. - Deferred searching:
I let end user to choose if he want to use Deffered Searching, because it is not so fluent and fast, but still, it's speed now is comparable to gridview without row virtualization - Checkbox column:
I've removed it. Here is some of my page opening measurements:
With checkbox:
1. 4.46 s
2. 4.59 s
3. 4.60 s
4. 4.60 s
5. 5.76 s
~ 4.80 s
Without checkbox:
1. 4.46 s
2. 3.35 s
3. 4.91 s
4. 4.34 s
5. 3.49 s
~ 4.11 s
and it is not about those 0.7 s, it is more about scrolling and working on gridview. Removing custom checkbox column, makes impression of completly fluent work on it. What is interesting, regular checkbox column defined as
<
telerik:GridViewSelectColumn
Name
=
"CheckBoxColumn"
EditTriggers
=
"CellClick"
>
</
telerik:GridViewSelectColumn
>
doesn't really affect fluency or time but custom one does.
As a conclusion, I wanted to point out that XAML really doesn't like null data, when you declare that you will provide not-null data. Remember to be really carefull about it.
Best regards,
Mateusz