Closing this bu then, since the refactoring of the TaskTree and some
additional modifications of the requester and core object since to have
sped thing up sufficiently now. As said by ploum in the previous
comment, please address any startup optimization bug in a separate bug.
** Changed in: gtg
Status: In Progress => Fix Committed
--
Taskbrowser refresh is way too slow
https://bugs.launchpad.net/bugs/351867
You received this bug notification because you are a member of Gtg
developers, which is subscribed to Getting Things GNOME!.
Status in Getting Things GNOME!: Fix Committed
Bug description:
Hey,
I recently stumble upon GTG and liked it instantly. Unluckily I have now
discovered (after filling 200+ taks via the quick add entry) that it is too
slow to be used productively.
- Filling the task on startup takes rather long. There should be nothing
complicated to it...
- Typing a word in the note name row freezes GTG for ~2seconds. The same
applies for adding a tag by typing @..
- Filtering of tags takes ~1 seconds, but this should happen instantly
I only had a short look at your code and saw threading, locking code and a
refresh method. Is that really needed?
Often in such simple applications pseudo threads via python generators and
gobject.idle_add are more than sufficient.
IMHO performance could be improved by several orders of magnitude if you use a
proper GTKTreeModel. With this at hand you don't need to care about updating or
redrawing your stuff. You should also consider wrapping your file/source
abstraction in a custom GTKModel that yields the correct signals when required
(not that difficult...)
I haven't looked at what happends when you add a tag. But maybe you can only do
(what ever you currently do) when I hit enter/linefeed or close the window.
Thanks and best Regards,
steve-e
_______________________________________________
Mailing list: https://launchpad.net/~gtg
Post to : [email protected]
Unsubscribe : https://launchpad.net/~gtg
More help : https://help.launchpad.net/ListHelp
