WindowTop causes significant background CPU usage while idling

[WindowsTablet]

Discussed in #368

^{Originally posted by WindowsTablet September 1, 2024}
WindowTop is a great utility, but it has one major problem. It idles in the background with significant CPU usage, even when none of its features are running, eating my battery away. It consistently shows at least 3% background in Windows "Battery usage" settings each day.

Could anything be done to improve this?

Thanks in advance.

[gileli121]

Hello, what windows do you have? (Windows 7/10/11)
Are you sure that none of the features are running?
I know that the Anchors may take some CPU

What version did you install?
Did you install it from the Microsoft Store or a regular installer? Is it the portable version?

On my system, the CPU usage is 0%.
I know that some older versions have CPU usage issues. But I fixed it long ago.

It is also possible that the high CPU usage is due to a weak CPU.
What CPU do you have? Any hardware info can be helpful

[WindowsTablet]

Hello, what windows do you have? (Windows 7/10/11)

Windows 11 - 24H2 Release Preview.

Are you sure that none of the features are running?
I know that the Anchors may take some CPU

Yes, I tried disabling everything, and still the same issue. I also tried disabling the window toolbar, on which I normally only have Always on Top and Dark Mode pinned. I even tried whitelisting to only one exe while every feature was disabled.

Did you install it from the Microsoft Store

Yes, paid MS Store version.

It is also possible that the high CPU usage is due to a weak CPU.
What CPU do you have?

Surface Pro 7, Intel® Core™ i7-1065G7.

But I’ve used many window manager utilities over the years, even much weaker CPUs, such as AquaSnap, TidyTabs, PowerToys - Always on Top and FancyZones, ActualTools - TitleButtons, etc, and those barely registered in the background.

From those I listed, I only still run PowerToys - FancyZones and ActualTools - TitleButtons at startup, which show <1% in the background.

My original plan was to fully replace ActualTools - TitleButtons with WindowTop, but due to the CPU usage, I now sadly have to manually run and exit WindowTop only for its Dark Mode during the night.

[gileli121]

@WindowsTablet
Thanks for the information.

The way to figure it out is to create multiple builds, each build with another part of code disabled, and see if the problem is fixed/reduced in any of these builds.
This way, I can determine what code may cause the extra CPU usage.

First, I need to verify that you can reproduce the issue on the portable version.
Can you please download it from here?:
https://github.com/WindowTop/WindowTop-App/releases

Let me know once you reproduce it with the portable version.

[WindowsTablet]

@WindowsTablet Thanks for the information.

The way to figure it out is to create multiple builds, each build with another part of code disabled, and see if the problem is fixed/reduced in any of these builds. This way, I can determine what code may cause the extra CPU usage.

First, I need to verify that you can reproduce the issue on the portable version. Can you please download it from here?: https://github.com/WindowTop/WindowTop-App/releases

Let me know once you reproduce it with the portable version.

Slightly better CPU behavior with the portable v5.23.3 version, but still too much. I roughly measured the difference in Process Explorer, by watching cycle count from startup after 1 minute.

[gileli121]

@WindowsTablet
Thanks for the information.
I will send you the builds to check this weekend.

[gileli121]

@WindowsTablet, Hello again.
After checks, I don't need to create multiple builds to test and report CPU usage changes.
There is a proper way to tell what code causes it (https://learn.microsoft.com/en-us/visualstudio/profiling/cpu-usage?view=vs-2022)

While checking it, it confirmed what I suspected—the code that causes a lot of CPU usage is the code responsible for checking the state (size, style, etc.) of every window.
The more windows you have open, the more CPU it can take.

The issue is that it is not event-driven. It is a loop that constantly checks the state of every window.
By disabling it, it reduces about 50% of the CPU time.

There is an easy solution—to use the OS's event-driven method —that I was not aware of while I wrote this code.
This means that instead of having code that asks the OS about the state of each window (which causes the extra CPU), the OS will notify the code when the state has changed.

Fortunately, changing it to event-driven seems like a simple task because I have already started changing some basic implementations, which allows me to do it more easily.

I will work on it when I get the time.

Thanks for the report.