CPU Usage when Idle Due to Timer

[Bill]

I have observed that any application with a RadGridView consumes CPU time even when the application is idle.  Using Spy++, you can verify this and see thousands of WM_TIMER messages being posted when a RadGridView is added to an application.  I have a simple repro app.  Full XAML below.  Just comment out the RadGridView, and the behavior goes away.  You can see using Process Explorer that even when the application is idle there is CPU usage, and using Spy++ you can see the timer events being fired rapidly.  This causes a large number of context switches and slows down performance noticeably.

Framework: .Net 4.5
Telerik Version: 2014.1.331.45

<Window x:Class="GridViewTimer.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:telerik="http://schemas.telerik.com/2008/xaml/presentation"
        Title="MainWindow" Height="350" Width="525">
    <telerik:RadGridView />
</Window>

[Nick]

Hi Bill,

I suspect the cause of the issue is a performance optimization in the PropertyChanged handling mechanism, however I cannot be certain this is the cause. Is this all the things required to reproduce the issue?
We will try to isolate it and will think of a way to deal with this issue, however if I am right and this indeed is the timer I mentioned for the optimization, this can take a while to refactor and redesign since it might introduce breaking behavioral changes for many of our clients. 

Regards,
Nik
Telerik

 

 

[Bill]

Hey Nik,
Yes just the simple app above is all that is required to repro.

-Bill

[Gareth]

I can confirm that we too also are now experiencing this problem when we have many windows open for some of our real-time applications. Even when the windows are empty doing nothing, the CPU usage is proportional to the number of windows opened.
This is going to cause us quite a few issues if it cannot be resolved.

[Nick]

Hi Gareth,

As previously stated. Changing the behavior could introduce a huge braking change, and we need to thoroughly test various scenarios before taking any action towards implementing an alternative solution. 

Thank you for the understanding. 

Regards,
Nik
Telerik

 

 

[Gareth Parris]

Hi Nik, can you advise if any further analysis has been done on this by Telerik yet. It is already causing problems and we've not released to our clients yet. We need a solution in time for F1 winter testing at the end of November and don't really want to look at other solutions at this late stage.

Thanks,
Gareth.

[Nick]

Hello Gareth,

There has been an optimization of the handling in our latest binaries, you can try them out to see if the problem still persist. 

The optimization we introduced is a very minor fix for some cases and might not affect your project, but for the time being this is the best we can do, without risking problems with most custom scenarios. We will continue investigating alternatives of the approach and will do our best to improve the handling procedure, however the earliest release, where we can introduce such a change, will be the ServicePack of our next official release.

Hope this makes sense.  

Regards,
Nik
Telerik

 

 

[Maarten]

Hi Nik,

I'm using the 2017 Q2 release, it's more than 2.5 years later now and the problem still exists. The PropertyChangedCheckerTimer still produces a fairly high CPU load. Any plans to change this?

thanks, Maarten

[Stefan]

Hello Maarten,

Actually, this default behavior of the control can be controlled as of Q2 2015 SP1. This can be done through the IsPropertyChangedAggregationEnabled property of RadGridView. You can check out the Degraded Performance topic for further reference.

Best Regards,
Stefan X1
Telerik by Progress