GTG

Parsing note title changes pegs slower CPUs

Bug #476477 reported by Jeff Fortin Tam
14
This bug affects 2 people
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! :)

Revision history for this message
Jeff Fortin Tam (kiddo) wrote :
Revision history for this message
Jeff Fortin Tam (kiddo) wrote :

Here's an epic video from my camcorder.

Jeff Fortin Tam (kiddo)
summary: - Taskbrowser refresh is too aggressive and pegs slower CPUs
+ Parsing note title changes pegs slower CPUs
Revision history for this message
Jeff Fortin Tam (kiddo) wrote :

Here are some further precisions resulting from investigations: this problem only happens with subtasks, and only when you are editing a subtask's title *from its parent task*. If you open the subtask in its own window (instead of opening the parent task) and edit the title, the light save's timer will be used.

My hypothesis is that somewhere, when editing the "bulleted-list-style" subtasks in a parent task, the old "save" method is used instead of "light_save".

However, even fixing this would still leave us with a problem: if you type continuously for more than 7 seconds, the "light save" will trigger "save" even though you are still typing, causing lag/an interruption while you type.

So there are two ways to solve this new problem:
- reset the timer everytime a letter is typed, and lower the timer limit to 3 seconds instead of 7; thus, no chance for the save to trigger while the user is still typing
- do not have a real-time save (light save) at all, and *only* save when the user closes the task editor or moves the focus away (the approach I've been advocating so far)

Revision history for this message
Jeff Fortin Tam (kiddo) wrote :

Any thoughts on this?

Revision history for this message
Luca Invernizzi (invernizzi) wrote :

Sorry for not answering you straight away. We are working on getting gtg leaner, but in these days we are mostly busy releasing version 0.2.
Closing this bug will require some refactoring and time, so it will be dealt with for the next version, 0.3.

Changed in gtg:
milestone: none → 0.3
importance: Undecided → Medium
Changed in gtg:
status: New → Confirmed
Revision history for this message
Paul Natsuo Kishimoto (khaeru) wrote :

Jean-François, is the binary attachment a result of pstats.Stats.dump()? If so, can you also upload a text dump (e.g. using pstats.Stats.print_stats()) to make this information more accessible for everyone?

Revision history for this message
Jeff Fortin Tam (kiddo) wrote :

The gtg.prof file is the result of the instructions on http://live.gnome.org/gtg/development
I think they did it that way so that the devs could dynamically sort the data to their liking, should I really make it a text version too?

Revision history for this message
Jeff Fortin Tam (kiddo) wrote :

Here's a text version of the profile data, limited to 20 entries and sorted by cumulative time.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.