Closed manuelVo closed 2 months ago
kdheepak
commented
3 months ago I think I know what is going on here, but I just realized recently that v3.0.0 has been released and there could be a lot of issues since I haven't tested it with that yet. I probably won't be able to look into it for at least a few weeks unfortunately.
kdheepak
commented
3 months ago I added a note to the README: https://github.com/kdheepak/taskwarrior-tui/commit/4902ecdb34c549ed917635cce13148c13ac46106
RedEtherbloom
commented
3 months ago From my limited debugging, thus far:
get_task_files_max_mtime fails due to the missing .data files. Due to this the faillsafe in the update loop(self.tasks_changed_since(self.last_export).unwrap_or(true)) kicks in, which leads to a force-update, recalculating nearly all internal state each tick.
What compounds this is that the task command in general seems to have gotten slower with the recent update. From the limited testing on my overworked Thinkpad X230 CPU: Before Taskwarrior 3: Average time for rendering the info of a single task: ~0.02s After Taskwarrior 3: Average time for rendering the info of a single task: ~0.09s
Due to these two compounding factors every single tick requires ~1.9s (310 active tasks) on my X230. (With ~50% spent on updating task details, 25% on ex/importing tasks on 25% project, context and tag updates collectively).
I tried to update get_task_files_max_mtime to check for the .sqlite3 database instead, but this failed. The new urgency in the database gets updated each export, changing the mtime and thus forcing the next export/flush immediately. Setting the export time at the end of the update cycle seems to be enough to fix this. (Export and summary seem to modify the sqlite database, info and context fortunately don't).
I'll prettify my fix later and open a PR.
(Unimportant sidenote: The update_task_details function should become significantly faster soon. I've been reworking update_task_details for the last few weeks, leading to a 3-3.5x performance increase for large batches of 100. It's less pronounced for smaller prefetch sizes, but definitely still significant. Only tests to write remain.)
kdheepak
commented
3 months ago Thanks for the detailed report! I'm going to be largely offline for the next couple of weeks but would love to take a look at it after. I'm curious about your performance improvements as well! Thanks for offering to make a PR!
RedEtherbloom
commented
3 months ago You're welcome!
Fix is available and turned out smaller than I thought.
Wishing you a pleasant vaccation(?).
GregPK
Describe the bug With the new Taskwarrior Version 3.0.0, taskwarrior-tui has a fairly high CPU utilization - enough to make my fans spin up. Oddly enough this only happens after deleting the old taskwarrior
.datafiles.To Reproduce
[ x] Reproducible using the test data located here: https://github.com/kdheepak/taskwarrior-testdata/
Update from taskwarrior 2 to 3 and migrate the data to the new sqlite based data format
Delete the old
.datafilesLaunch taskwarrior-tui. It'll use noticable CPU resources while idle
Steps to reproduce the behavior: Environment (please complete the following information):
Here is a log for taskwarrior-tui running for roughly 2 seconds with the
.datafiles removed (cpu usage is high):Here is a log for taskwarrior-tui running for roughly 2 seconds while the
.datafiles still exist (cpu usage is low):