gtg team mailing list archive

[Lionel Dricot <ploum@xxxxxxxxx>]

*** This bug is a duplicate of bug 486867 ***
    https://bugs.launchpad.net/bugs/486867

** This bug has been marked a duplicate of bug 486867
   Remove the need for a systematic browser global refresh when tasks are changed

-- 
Parsing note title changes pegs slower CPUs
https://bugs.launchpad.net/bugs/476477
You received this bug notification because you are a member of Gtg
contributors, which is subscribed to Getting Things GNOME!.

Status in Getting Things GNOME!: Confirmed

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! :)