Hi JF,

Actually we should get rid of this by handling correctly the
treeviews. This means reimplementing completely the way we generate
the content of what we display to do it in a more gtk-ish way.
Unfortunately it also means that we'll have to rethink a part of our
data structures, something this always painful to do. I'm planning to
complete this ASAP since it is a much needed work before GTG could go
further.

By the way, you're right: we should certainly prevent GTG from doing
unnecessary work. However it could be possible that a change in the
title we'll be efficiently handled by the use of signals, etc.
(treeviews are actually quite well thought). Some work will probably
be also needed at the editor level, to prevent throwing a signal when
the user hasn't changed the title.

On Fri, Jul 10, 2009 at 4:27 AM, Jean-François Fortin
Tam<email address hidden> wrote:
> Looking forward to this, as the sluggish performance prevents me from
> using GTG at all (I hit the performance bottleneck with 70 tasks or so).
>
> In the meantime I'm still using Tasks (now *THAT* is the kind of
> performance I expect for a GTG app to be "pleasurable" like Mr. Allen
> suggested in his book). Hopefully I'll be able to give GTG another try
> when 0.2.x comes out.
>
> I lack the knowledge to help implement a fix, but I do 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
> algorythms 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)!
>
> --
> 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 the registrant for Getting Things GNOME!.
>
> Status in Getting Things GNOME!: Confirmed
>
> 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
>



-- 
Bertrand Rousseau
Place communale 1, 1450 Chastre, Belgium
e-mail : <email address hidden>
tel : +32 485 96 69 86