[Performance Bug] Many tasks cause GUI to be slow, *so only load visible tasks*.

[RokeJulianLockhart]

Steps to reproduce

1. Load a task list like https://wim.nl.tab.digital/apps/tasks/#/collections/all.
2. • Modify a task and wait for it to update.
   • Sometimes, scrolling can be slow, too.

Expected behavior

The tasks should be dynamically loaded as they are viewed.

Actual behaviour

All of the tasks are preloaded at initialization time. This makes it hideously slow when many tasks exist.

Tasks app version

Unfortunately, https://help.nextcloud.com/t/get-version-of-app/97847/5?u=rokejulianlockhart + | Select-String 'tasks' doesn't return anything.

CalDAV-clients used

https://github.com/tasks/tasks/releases/tag/13.6 as https://f-droid.org/repo/org.tasks_130605.apk from https://f-droid.org/en/packages/org.tasks/.

Browser

https://download.opensuse.org/repositories/openSUSE:/Factory/standard/x86_64/MozillaFirefox-120.0.1-1.1.x86_64.rpm

Client operating system

cpe:/o:opensuse:tumbleweed:20231218

Server operating system

404 pages report:

(Ubuntu)

Web server

404 pages report:

nginx/1.18.0

Database engine version

Other

PHP engine version

Other

Nextcloud version

25.0.8.2, according to https://scan.nextcloud.com/results/e9c6cb22-1bf8-424a-9aec-2ba3ce521bac.

Updated from an older installed version or fresh install

Updated from an older version

List of activated apps

1. https://wim.nl.tab.digital/apps/dashboard/
2. https://wim.nl.tab.digital/apps/files/
3. https://wim.nl.tab.digital/apps/photos/
4. https://wim.nl.tab.digital/apps/activity/
5. https://wim.nl.tab.digital/apps/spreed/
6. https://wim.nl.tab.digital/apps/mail/
7. https://wim.nl.tab.digital/apps/contacts/
8. https://wim.nl.tab.digital/apps/calendar/
9. https://wim.nl.tab.digital/apps/notes/
10. https://wim.nl.tab.digital/apps/deck/
11. https://wim.nl.tab.digital/apps/tasks/

Nextcloud configuration

No response

Web server error log

No response

Log file

No response

Browser log

https://gist.github.com/RokeJulianLockhart/c99f881a03aa9f60e97457be1837802b#file-identifier-so6mr7-txt-log

Additional info

https://github.com/tasks/tasks/releases/tag/13.6 reports +1074 (although the server won't tell me, due to #2416 (comment)).

[raimund-schluessler]

We already do what we can here. But this is unfortunately limited to not loading completed tasks by default.

Your proposal to only load tasks as they are viewed seems a bit difficult to me, because how are we supposed to know what to load when we do not know what is there (because we didn't load the tasks)?

We could of course disable some lists completely and exclude them from loading, but that is a different issue really.

[RokeJulianLockhart]

#2417 (comment)

@raimund-schluessler, I don't quite understand - if the completed tasks need to be loaded to provide dynamic loading, then load the completed tasks. If the tasks were dynamically loaded based upon viewport size as I request, there's no need to not load the completed tasks.

[raimund-schluessler]

This is not about completed tasks. I just said we do not load them at the moment to speed up the app.

My remark was more about how we should know "based on the viewport" what to load. If the tasks existing on the server are unknown to the app, because we did not load them from the server, the concept of viewport is useless. There is no way to create a view in the first place, without knowing what to show.

[RokeJulianLockhart]

#2417 (comment)

@raimund-schluessler, is the configuration you refer to fundamentally different to how most software with dynamic loading performs this? I'm not much of a GUI software developer, so I can't help much regarding implementation details other than regurgitate what appear to be best practices, but I doubt that NC Tasks does anything which would make this infeasible.

[raimund-schluessler]

#2417 (comment)

@raimund-schluessler, is the configuration you refer to fundamentally different to how most software with dynamic loading performs this?

You seem to mix-up dynamic rendering with dynamic loading of data. We could of course only render/show the tasks you are currently looking at (this is dynamic rendering), but we would need to load the data from the server before-hand no matter what. Otherwise, we would not be able to decide what to render.
But as you can guess, already loading 1000+ tasks from the server and then working our way through that pile of information (which task belongs where, how many are priority, what is due when, what are sub-tasks etc.) takes a lot of time. So dynamic rendering would not help much here anyway.

I'm not much of a GUI software developer, so I can't help much regarding implementation details other than regurgitate what appear to be best practices, but I doubt that NC Tasks does anything which would make this infeasible.

Hm, I see.

I am sorry to say, but if you try to manage 1000+ tasks in a CalDAV client, there might be a problem inherent to your current software choice. This software is for synchronization, often between mobile clients. There is no possible way you can keep the overview of so many tasks on a phone. And I even doubt that it makes sense to look at 1000+ tasks at the same time at all. I don't exactly know your use case, but I am quite sure there is software better suited for your needs, e.g. for issue tracking like GitLab or GitHub.

[RokeJulianLockhart]

#2417 (comment)

@raimund-schluessler, I very easily keep track of my tasks. If you break each task down into a lot of subtasks, they very quickly become of a significant amount. Solely on wim.nl.tab.digital/apps/tasks/#/calendars/3de72895-d345-4ac4-8eec-1418e857ba7e is this a problem — tasks/releases/tag/13.6 handles this fine, so this is an issue with ≤ tasks/releases/tag/v0.15.0.

I did try to capture a performance profile, but the tab, ¹² and then firefox, crashed. ³

Additionally, firefox about:processes reports the undermentioned:

Considering that Chrome reports the undermentioned, I don't consider this a WebCompat issue either. That value varies from 8×10⁵ depicted to 1×10⁶, like in FF.

Footnotes

1. https://share.firefox.dev/41jdWvn ↩

2. https://share.firefox.dev/3VvkEum ↩

3. https://bugzilla.redhat.com/show_bug.cgi?id=2331030#c0 ↩