1-second lag when clicking tags in tag list

[Bryce Harrington]

There is a minor but irritating performance issue when clicking on tags in the tag side-panel - it takes on the order of 1 second for the tag to get highlighted and the task list window to update.

I imagine the slowness is due to performing some sort of query on an internal data structure, so wonder if this could be made more efficient or cached in some fashion. Alternately, maybe the performance issue could be hidden by highlighting the tag right away and clearing the task window while it is doing its calculations (or maybe that would be just as ugly?)

[Bertrand Rousseau (bertrand-rousseau)]

I don't have this bug on my computer. However, it could very well be that we have different task lists and that your configuration induce a performance problem we haven't experienced yet. Could you describe how many active/tags/closed tasks you have? Are your tasks heavily tagged?

You could also provide us profiling information by following instructions on this page: http://live.gnome.org/gtg/development.

[Lionel Dricot (ploum-deactivatedaccount)]

Hi,

I think that this is in fact the same bug as bug #476477

Currently, the datastore has a big list of tasks (all of them) and, each time you change your view, this list is parsed to build a Tree() corresponding to what you are asking for. (in fact, 2 Trees are built, one for open, other for closed tasks).

My solution is to make the Datastore directly stores 2 Trees : one for open and other for closed. Views will use filtering capabilities of gtk.Treeview.

This planned refactoring should improve performances *a lot*. I plan to do that in the following weeks (as I already did exactly that for the Tagstore, that was suffering the same fate but with less impact as you have less tags than tasks)

Second step will be to change the closed tasks Tree() to only have tasks closed in the last XXX days.

I plan to do that soon.

[Bertrand Rousseau (bertrand-rousseau)]

I forgot about it: there's actually a "profile.py" script in the GTG trunk that takes care of doing all this.

[Bryce Harrington (bryce)]

Okay thanks. It sounds like Lionel's refactoring will solve the issue I'm seeing. If it doesn't, I'll do the profiling to see what causes the slowness.

> Could you describe how many active/tags/closed tasks you have? Are your tasks heavily tagged?

I've got around 320 open tasks, and I suppose a couple hundred closed. There are perhaps 35 tags. Most tasks have one tag, some have two tags, and a small number have three tags.

[Chris Johnston (cjohnston)]

I can confirm that I do notice the slowness talked about in the bug report.