This is a migrated thread and some comments may be shown as answers.

Styles warning - how to avoid huge performance issues

1 Answer 71 Views
This is a migrated thread and some comments may be shown as answers.
Top achievements
Rank 1
Mateusz asked on 03 Sep 2018, 09:31 AM

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"
       BasedOn="{StaticResource GridViewRowStyle}">
    <Setter Property="Background"
            Value="{Binding Color}" />
    <Setter Property="Foreground"
            Value="Black" />
    <Setter Property="BorderThickness"
            Value="0 0 1 0" />


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:

                                   <CheckBox IsChecked="{Binding CzyMagWyprz, Mode=TwoWay}"
                                             Unchecked="ToggleButton_OnChecked" />
    Maybe I've implemented it somehow wrong, but such checkbox column causes increased render times for page, with and without virtualization. 

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"

    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, 


1 Answer, 1 is accepted

Sort by
Dilyan Traykov
Telerik team
answered on 05 Sep 2018, 01:20 PM
Hello Mateusz,

Thank you very much for sharing your experience with the community. I do hope the performance of your application at the moment is acceptable.

If you do require any further optimizations, feel free to open a new support ticket, preferably with a small sample project which demonstrates the issue and we will happily assist you.

Dilyan Traykov
Progress Telerik
Get quickly onboarded and successful with your Telerik and/or Kendo UI products with the Virtual Classroom free technical training, available to all active customers. Learn More.
Asked by
Top achievements
Rank 1
Answers by
Dilyan Traykov
Telerik team
Share this question