Constant CPU usage drains battery

[oktayacikalin]

Describe the bug Planify is using about 13 to 23% of cpu, as seen in top. Even when minimized.

To Reproduce

1. Run Planify
2. Let it sync with NextCloud
3. Wait until it's idle
4. Check top (when cpu idles at about 800 MHz)
5. Minimize Planify
6. Check top (when cpu idles at about 800 MHz)

Expected behavior When Planify is visible, I could understand some percent of cpu usage, although 20% for my system is too much. But after minimizing it, I would expect it to be around 0-1% when not doing anything. Firefox is going down to 2-3% while having this bug report open.

Screenshots

Desktop:

• Fedora Workstation 39 with GNOME Shell 45.4
• Planify 4.5 from Flathub
• Intel® Core™ i5-3337U with 1,8 GHz (w/o boost) with 8 GB of ram

Additional context none

[oktayacikalin]

I've seen that Planify can go to idle mode, but only when I'm in a project/list view. When I'm on the pinboard, it's about 30% cpu.

When I try to open the today view, it seems to go into some infinite loop and grows into the GB range for now reason. But I've also seen that the today view of NextCloud bails out too. There's certainly something bad after all that testing. How can we debug this? It would be great if Planify could detect such loops and help me fix it.

[alainm23]

I haven't tested the app with many tasks, I'm still looking for a solution for this.

[oktayacikalin]

Are there event listeners or something which only fire when the app is visible? As of now, when I hide the app, CPU goes down to 0%. But when I pull it up, focused or not, it consumes a lot of CPU, as if something is constantly doing/drawing or scanning something. Keyboard event polling or something?

It also increases with the amount of tasks in view. For example, my personal list is long, the test lists are short. This can be seen in the amount of cpu usage.

I've also the impression, that the longer the app runs or the often I pull it up again (from hidden state), something adds up and the CPU usage increases.

All blackbox testing so far.. perhaps I should start reading code again 😅

[oktayacikalin]

Bildschirmaufzeichnung vom 2024-03-08, 10-38-12.webm

[oktayacikalin]

If you like, I can try to take a look at it. But you should help me setting up a proper dev environment. I have some experience with GTK3 und Python2/3, but not with libadwaita - and I haven't written code for some time now.

[oktayacikalin]

1. When I minimize Planify the CPU usage goes down to kind of 0%.
2. Then I go into GNOME's overview mode.
3. Planify has to update it's window and CPU usage is up again.
4. Exit overview mode, not selecting Planify.
5. Planify keeps updating its window and CPU usage stays up.

It looks like Planify is not recognizing that it is minimized again and should not update its window.

[jadahl]

Another observation from the side lines:

While a todo item is expanded (edited), the CPU usage goes down to ~0%. As soon as I collapse it / leave the edit mode, it goes up to a constant ~12% CPU usage.

[zhrexl]

There are 2 others related reports (#1333 and #1265) that I think should be closed for organizational reasons.

I haven't tested the app with many tasks, I'm still looking for a solution for this.

There's no need to test the app with many tasks, the CPU usage increases almost the same amount of % for each task added, that implies it's some kind of check/event controller/signal being emitted in a loop for each task added.

Running sysprof I got similar results as in another report. The source of the problem seems to be a huge amount of calls to g_source_emit, the number of calls increases with the number of tasks in the list.

@alainm23 would you mind sharing your thoughts on this? I'm not used to vala but if you have any hint I might look into it to find the culprit.

Also, the CPU increase rate by task added seems to be bigger on sync tasks (both todoist and nextcloud), but it also happens in a minor scale with local tasks.

[alainm23]

Hi guys, I am aware of this problem and I am still trying to find the solution, in fact it uses a lot of signal to connect the add, update and delete events. Planify 4.10 will be out next week and support for multiple online accounts will be supported, after that I will prioritize performance improvements, thanks for using Planify.

[zhrexl]

Hi guys, I am aware of this problem and I am still trying to find the solution, in fact it uses a lot of signal to connect the add, update and delete events. Planify 4.10 will be out next week and support for multiple online accounts will be supported, after that I will prioritize performance improvements, thanks for using Planify.

Don't worry! My intention was to collaborate.

Thank you so much for all your effort. This is definitely the best productivity app we have in the linux community.