Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Many recurring tasks lead to slugginess in app interface and slow synchronization #1660

Open
sssammm88 opened this issue Dec 14, 2024 · 1 comment
Assignees
Labels
bug Something isn't working

Comments

@sssammm88
Copy link

Describe the bug

Thanks for this great app @patrickunterwegs, which I discovered & adopted recently.

I also have quite a bunch of recurring & non recurring tasks myself in the app (about 5800 tasks are shown in the app) and I experience the same sluggishness & issues as described in : #1071 (I originally commented there). I strongly suspect this is related to the recurrence feature. In order to see if it was the case, I also did some testing myself.

To Reproduce

I replicated the protocol of @jackrgm

Note: 'limit recurring' was enabled, all task fields default except where noted.

  1. Create CalDAV collection 'tmp_jtx_recurringbug'. Disable all other collections in DAVx5.

  2. Create task 'SINGLE'. jtx Board reports 1/1 tasks in list.
    a. Leave app after creating task. Wait for app to unload or force stop the app.
    b. Return to app. Open task to view details, then return to task list. Repeat at least four times; loading of details page generally feels responsive.
    c. Delete task 'SINGLE'. jtx Board reports 0/0 tasks in list.

  3. Create 'RECUR_1' - start today at 9am. Repeat every 1 day(s) ends never. jtx reports 1/366 total entries in the task list.
    a. Leave and return to app as in step 2.
    b. Open task to view details, then return to task list. Repeat at least four times; loading of details page includes a quick pause (82ms avg. on the stopwatch?) but otherwise feels responsive.

  4. Create 'RECUR_2' - same task settings as RECUR_1. jtx Board now reports 2/732 total entries (366 new recurring entries added).
    a. As in previous steps, leave and return to app, open task(s) to view details. About the same level of responsiveness.

  5. Create 'RECUR_3' - same task settings as RECUR_1. jtx Board now reports 3/1252 total entries (not sure why 520 recurring entries were added this time).
    a. As in previous steps, leave and return to app, open task(s) to view details. Task list starts empty with a noticable pause before entries quickly appear. View details page is perhaps the same, perhaps slower, hard to say.

  6. Create RECUR_4 - same as RECUR_1. jtx Board now reports 4/1618 total entries (it created 366 recurring entries this time).
    a. As in previous steps, leave and return, etc. - Task list now starts empty with a considerable pause time (about twice as long as last time) before entries appear. Viewing task details has a varying rate of responsiveness each time, but generally a noticeable sense of slowness.

  7. Create RECUR_5 - same as RECUR_1. jtx Board now reports 5/1984 total entries (366 new). Experienced general sluggish and slow performance while creating the task.
    a. As in previous steps, leave, return, etc. - task list is even slower than last time in loading entries in the list (I suspect this will grow for each daily recurring task added). Viewing task details responsiveness varies, but generally feels sluggish and slow to load.

I got essentially the same results as in the post above, with some small differences:

  • The "correct" amount of new tasks was created every time (366)
  • I didn't experience sluggishness when going to the description & back to the main menu during the test, but I do experience it in my normal "big" tasks list
  • Every addition of a daily infinite recurring time increased the sync delay with the server of about 3 seconds (9 seconds with 3 tasks, 12 with 4, 15 with 5)
  • Starting from 5 recurring tasks, I had to wait about 1 second between pressing the checkbox icon and having the task being marked as complete. In my usual big list of tasks, the delay is about 10-15 seconds. This is true even in the absence of any task modification
  • In the test mode, if I delete 4 out of 5 recurring tasks, the app is fully reactive again.
  • After starting the resyncing the original list of tasks, I get the following error: Local storage error : Couldn't apply batch operation. Retriggering the sync increases the number of displayed list of tasks of about 500

To summarize, the app is functional, but very slow in my usecase.

Expected behavior

Even with recurring tasks, the app remains responsive and the synchronization takes a few seconds.

Device and version

Device: Google Pixel pro 8
OS: GrapheneOS (Android 15)
Version: 2.09.02.ose (209020004)
Downloaded from: F-Droid
Synchronization: DAVx5 (4.4.4-ose) on Nextcloud Server

Synchronization also done smoothly with Thunderbird.

Let me know if I can help further here (eg. via testing) and thanks again for the work put in this app. I really appreciate when someone puts value in correct standard implementation (which is far from being the norm with task management app IMO).

ps. I'm quite new to contributing to open source projects. My apologies if I overlooked a code of contribution or something similar.

@sssammm88 sssammm88 added the bug Something isn't working label Dec 14, 2024
@sssammm88
Copy link
Author

To see if the issue would be related to DAVx5 only, I deactivated sync & imported my usual big list of tasks into a local list. Although the interface was a bit more reactive, I still had to wait a 1-2 seconds to get a task validated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants