Windows dispatcher idle performance

[ltetak]

Describe the bug

I see a blocked CPU time on Windows dispatcher (main thread). Around 10% on my machine. It might be just my incorrect measurement, but if true, then it is quite a significant performance hog.
I assume the problem is that scheduling and killing the system timer is not optimal.

To Reproduce

Run an empty app on Windows.
Performance profiler says UpdateTimer method takes ~10% of the main thread time. This is a problem if you want to run a lot on the main thread. You can not use it up to 100%.
CPU usage is around 0.3%, which is almost nothing. But those 10% are probably blocked and unusable anyway.

Expected behavior

idle time is 0% CPU wasted, no blocked main thread
When I run the app and then comment out the UpdateTimer method, I see the dispatcher thread still ticking, and there is no blocking and 0% CPU in Task Manager.

Avalonia version

11.3.1

OS

Windows

Additional context

UpdateTimer method
https://github.com/AvaloniaUI/Avalonia/blob/master/src/Windows/Avalonia.Win32/Win32DispatcherImpl.cs#L41

Note that the Windows timer granularity is 15.4ms, so 1ms as a minimum is very optimistic. But that still means this method is invoked a lot of times per second.

[maxkatz6]

Current implementation, as well as a minimum, was ported from WPF I believe https://github.com/dotnet/wpf/blob/7f349080dc655745896d942d3e8329539ef35917/src/Microsoft.DotNet.Wpf/src/WindowsBase/System/Windows/Threading/Dispatcher.cs#L2643-L2657. In reality I believe it's not invoked with actual minimum value, but computed from the current dispatcher timers.

[maxkatz6]

But another question is if we need any timers to be running on app idle.
For an empty app, there seems to be: BatchStreamPoolBase.StartUpdateTimer running each second. cc @kekekeks

[maxkatz6]

Performance profiler says UpdateTimer method takes ~10% of the main thread time.

I checked with dotTrace, and couldn't find anything even close to these numbers. I used an empty sandbox app. Is there another repro?

[ltetak]

Well, there are at least two questions. 1. is it slow? 2. is it needed? I think if 1. can't be reproduced, then 2. is not important. I can reproduce it on my machine if you need any more testing.
Is it slow?
I could see some blocked CPU time even with the latest version (current master branch).
Find the UpdateTimer method.
It also seems the KillTimer is the culprit.

When I debugged the native stack trace, they are entering the critical section, so they are definitely doing some thread synchronization there. Documentation says these calls should be very quick and non-blocking, but apparently they are not. KillTimer should just find the timer in the timers collection, and that probably requires a lock. SetTimer just appends it, so it may not.

Make sure to have all "native" or "system" tracking enabled. It might be filtered out by dotTrace.

It may depend on my machine, my Windows, my quantum state of everything else running atm. I haven't tested all combinations.

Is it needed?
Here I just guess. I think these threads are used for some periodic updates. I am not sure if it tries to make it behave as a sliding timer (if the dispatcher is busy, it does not want to queue too many wm_timer messages, would it be a problem?). The default SetTimer behavior is that it will reschedule it over and over.

[ltetak]

Interesting, chatbot thinks KillTimer can be blocking if called from inside the WM_TIMER handler

[xland]

I don't think Avalonia is a real-time UI framework, so it shouldn't be consuming 0.3% of the CPU.
This is very important for a product that stays resident in the user's system.
We shouldn't sacrifice this level of performance just to maintain compatibility with WPF.

[kekekeks]

Interesting, chatbot thinks KillTimer can be blocking if called from inside the WM_TIMER handler

WPF is doing exactly that: https://github.com/dotnet/wpf/blob/main/src/Microsoft.DotNet.Wpf/src/WindowsBase/System/Windows/Threading/Dispatcher.cs#L2229-L2236

We might be trying to remove a non-existing timer though, try replacing UpdateTimer with something like this:

    private long? _timerSetTo;
    public void UpdateTimer(long? dueTimeInMs)
    {
        if (dueTimeInMs == null)
        {
            if(_timerSetTo.HasValue)
                KillTimer(_messageWindow, (IntPtr)Win32Platform.TIMERID_DISPATCHER);
        }
        else if(_timerSetTo != dueTimeInMs)
        {
            var interval = (uint)Math.Min(int.MaxValue - 10, Math.Max(1, Now - dueTimeInMs.Value));
            SetTimer(
                _messageWindow,
                (IntPtr)Win32Platform.TIMERID_DISPATCHER,
                interval,
                null!);
        }

        _timerSetTo = dueTimeInMs;
    }

[ltetak]

@kekekeks I haven't run the WPF code, but it looks like they start the timer only if there is user input queued and there is background work to be processed. That's probably very rare, especially when the application is idle.
Avalonia schedules it all the time when you exhaust the dispatcher jobs queue (if I read it correctly). Which is almost always, especially when the application is idle.

the patch makes it much faster, although not zero (617ms vs 159ms in a 10s long session)

[kekekeks]

WPF has two separate timers, one for, well, timers, another for background work. Avalonia uses a single timer for both.