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

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.

from tasks.

#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.

from tasks.

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.

from tasks.

#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.

from tasks.

#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.

from tasks.

#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 https://wim.nl.tab.digital/apps/tasks/#/calendars/3de72895-d345-4ac4-8eec-1418e857ba7e is this a problem — https://github.com/tasks/tasks/releases/tag/13.6 handles this fine, so this is an issue with <= https://github.com/nextcloud/tasks/releases/tag/v0.15.0.

Regardless, I've got some data which might be useful — https://profiler.firefox.com/from-browser/calltree/?globalTrackOrder=xawxc0wx9&hiddenGlobalTracks=1wx0x2wx5x7x8&hiddenLocalTracksByPid=8984-0wk~25346-0~22244-0~9398-01~9374-0~9615-0~25349-0~22342-0~9511-0~9258-0~9206-01~9200-0~9643-01~9284-0~9321-01~23652-0~9232-0~11039-0~13032-0~9217-01~15233-01~9461-0w3~11043-0w6~10100-0wd~9193-0&thread=y8&v=10 is during usage (I created and modified a task's Notes) whereas https://profiler.firefox.com/from-browser/calltree/?globalTrackOrder=x8wxa0wx7&hiddenGlobalTracks=1wx2x4wx6&hiddenLocalTracksByPid=8984-0wi~9398-01~9232-0~22342-0~9615-01~9206-01~9258-0~9374-0~22244-0~9643-01~9217-0~9321-01~23652-0~9511-0~9200-0~25432-0~9284-0~11039-0~15233-01~13032-0~27090-01~9461-0w3~11043-0w6~10100-0wd~9193-0&thread=ye&v=10 was recorded during reinitialization of the https://wim.nl.tab.digital/apps/tasks/#/calendars/3de72895-d345-4ac4-8eec-1418e857ba7e/tasks/DA948B71-7F61-47AC-A8A0-AA250B43AFC8.ics tab. All recorded in https://download.opensuse.org/repositories/openSUSE:/Factory/standard/x86_64/MozillaFirefox-123.0.1-1.1.x86_64.rpm.

Additionally, firefox about:processes reports

Considering that Chrome reports

I don't consider this a https://webcompat.com/issues/new either. That value varies from 8×10^5 depicted to 1×10^6, like in FF.

from tasks.