Parsing note title changes pegs slower CPUs
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
GTG |
Confirmed
|
Medium
|
Unassigned |
Bug Description
Continuation from bug #351867 as a fresh bug, for clarity.
With processors such as the Atom (in the majority of netbooks), if you have 60+ tasks, typing anything that changes the title of a note (and tags?) will freezes GTG for many seconds.
After bug #351867 was closed, with today's bzr version of GTG, the performance "while typing tasks" is still abysmal here. The atoms are really, really, much less potent than an average 3 years old cpu; then at the same time it's kind of a good thing, it exacerbates performance bottlenecks so they are clearly visible.
Now you can understand why I said this in the previous bug report ;-) :
"I have some basic notions of performance profiling (taken from Federico's fosdem talk in 2007), and this basically sounds to me like the app is, first and foremost, doing unneccessary work (before we start looking into algorithms and such). It begs the question: why does GTG refresh the treeview everytime you type a character in a note title? It should do that only once (when the user moves the focus out of the note's title)!"
[...]
"And again, as the proposed fix (refactoring the hell out of gtg) seems quite complex, I have to reiterate the question: why not just limit GTG to refreshing the treeview only when the user moves the focus out of the note's title (instead of in realtime), as a stopgap measure?"
It's a friggin' task/todo application, it should be able to run on a 286, not require a friggin' Core2Quad! :)
summary: |
- Taskbrowser refresh is too aggressive and pegs slower CPUs + Parsing note title changes pegs slower CPUs |
Changed in gtg: | |
status: | New → Confirmed |
Here's an epic video from my camcorder.