GTG

cleanup feature

Bug #495758 reported by Jeff Fortin Tam
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GTG
Fix Released
Wishlist
Luca Invernizzi

Bug Description

I would like having an option to "Delete all done tasks", or maybe even an option to "Delete done tasks automatically after a week".

Surely, keeping those hundreds of done tasks in the gtg db can't be good for performance.

Related branches

Changed in gtg:
importance: Undecided → Wishlist
milestone: none → 0.3
Revision history for this message
Bryce Harrington (bryce) wrote :

Can anyone confirm whether having the done tasks affects performance significantly? I ask because I'm starting to notice now periods where gtg "hangs" and I'm wondering if the xml file size (or its representation in memory) should be a concern?

Revision history for this message
Jeff Fortin Tam (kiddo) wrote : Re: [Bug 495758] Re: cleanup feature

>From my experience, it is a certainty that letting the XML files grow
with no bounds and no cleanup features will definitely impair
performance in a significative way down the line; now, I'm not sure at
what point it will be really apparent. Up until recently, GTK did not
trim the ".recently-used.xbel" file, and it inflated to huge proportions
over the years (hundreds of thousands of lines in my case), and
applications such as gedit ate the CPU and took over 5 seconds to save
(instead of saving instantaneously) because they had to write to that
file.

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

I do feel GTG to be a bit sluggish for some operations (such as loading
the initial list of tasks), but this shouldn't be related to the
filesize of my current xml file (it's "only" 70 Kib, instead of being
megabytes). I'm thinking that there may also be other types of
bottlenecks in the application and how it manages data in general, you
could take a look at profiling it (see
http://live.gnome.org/gtg/development )

By the way, that wiki page seems incorrect:
pstats.Stats('gtg.prof')

Shouldn't be (if I remember correctly):
p = pstats.Stats('gtg.prof')

Revision history for this message
Lionel Dricot (ploum-deactivatedaccount) wrote :

Bryce : it's clearly a concern due to the fact that all tasks are stored the same way and the filtering out of done tasks is done dynamically with each window refresh.

We will do a refactoring to avoid this problem "soon" (I've a clear view how what should be done, I just need some time, probably end of February, before attacking the multi-backends)

Revision history for this message
Bryce Harrington (bryce) wrote :

On Thu, Jan 21, 2010 at 08:46:39AM -0000, Lionel Dricot wrote:
> Bryce : it's clearly a concern due to the fact that all tasks are stored
> the same way and the filtering out of done tasks is done dynamically
> with each window refresh.

Good to know.

> We will do a refactoring to avoid this problem "soon" (I've a clear view
> how what should be done, I??just need some time, probably end of
> February, before attacking the multi-backends)

A stopgap of just a simple command-line tool to delete the Done tasks
(or move them into a foo-archive.xml file) might be worth considering.

Changed in gtg:
status: New → Triaged
Revision history for this message
Luca Invernizzi (invernizzi) wrote :

Instead of adding new dialogs for this, we should just add support for multiple selection in the closed task pane.
This way, the user could, once a month, clean up the tasks. It's way better than doing it automatically, since tasks can hold important bits of informations in their description (like the emails do).

Changed in gtg:
status: Triaged → Confirmed
Revision history for this message
Jeff Fortin Tam (kiddo) wrote :

I would still like the option for it to be done automatically ever x weeks or something. I am among the users who *never* open the "Closed tasks" pane.

This is in the same line of thought as http://open-source.ecchi.ca/?voir=articles/dont_care_about_trash

Changed in gtg:
assignee: nobody → Luca Invernizzi (invernizzi)
Revision history for this message
Bryce Harrington (bryce) wrote :

On Fri, Feb 12, 2010 at 12:52:47PM -0000, Jean-Fran??ois Fortin Tam wrote:
> I would still like the option for it to be done automatically ever x
> weeks or something. I am among the users who *never* open the "Closed
> tasks" pane.
>
> This is in the same line of thought as http://open-
> source.ecchi.ca/?voir=articles/dont_care_about_trash

If the concern is deleting tasks which may have useful notes, couldn't
the trash collector simply check and exclude reaping tasks with textual
descriptions set?

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

Committed a plugin implementing this feature to trunk. Please test it, tell me if you like it, and if you have a better name, tell me that.

Changed in gtg:
status: Confirmed → Fix Committed
Revision history for this message
Jeff Fortin Tam (kiddo) wrote :

The name sounds fine to me. The configuration dialog could be improved
in terms of looks/spacing/etc., but I don't know how flexible that thing
is. At least, the following checkbox label:

    Add the menu Plugins>Delete old tasks to manually delete them

Should instead read:

    Add the "Plugins > Delete old tasks" menu item

Furthermore:
- the "Task Reaper Plugin configuration" label is redundant, it should
be in the window title instead of "gtg".
- it doesn't work, sadly... My tasks don't seem to be deleted, and there
is no "Plugins" menu at all. Don't know if this is to be expected.
- the option to add a menu item: shouldn't it go in the "Tasks" menu
instead of a (nonexistent) "Plugins" menu?
- the option to add a menu item... is it really necessary? Who would not
want that option anyway?

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

I'll apply the changed suggested.
About the plugins menu, it was incorrectly deleted in the latest merge.
It's available in r624. I'm going to fix it now.
Anyway, that menu is not specifically for this plugin, but is in
common to all plugins. You should really see r624 :-D

On Mon, Feb 15, 2010 at 3:15 PM, Jean-François Fortin Tam
<email address hidden> wrote:
> The name sounds fine to me. The configuration dialog could be improved
> in terms of looks/spacing/etc., but I don't know how flexible that thing
> is. At least, the following checkbox label:
>
>    Add the menu Plugins>Delete old tasks to manually delete them
>
> Should instead read:
>
>    Add the "Plugins > Delete old tasks" menu item
>
> Furthermore:
> - the "Task Reaper Plugin configuration" label is redundant, it should
> be in the window title instead of "gtg".
> - it doesn't work, sadly... My tasks don't seem to be deleted, and there
> is no "Plugins" menu at all. Don't know if this is to be expected.
> - the option to add a menu item: shouldn't it go in the "Tasks" menu
> instead of a (nonexistent) "Plugins" menu?
> - the option to add a menu item... is it really necessary? Who would not
> want that option anyway?
>
> --
> cleanup feature
> https://bugs.launchpad.net/bugs/495758
> You received this bug notification because you are a bug assignee.
>
> Status in Getting Things GNOME!: Fix Committed
>
> Bug description:
> I would like having an option to "Delete all done tasks", or maybe even an option to "Delete done tasks automatically after a week".
>
> Surely, keeping those hundreds of done tasks in the gtg db can't be good for performance.
>
>
>

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

The plugins menu is now shown if a plugin requests it.

On Mon, Feb 15, 2010 at 3:30 PM, Luca Invernizzi <email address hidden> wrote:
> I'll apply the changed suggested.
> About the plugins menu, it was incorrectly deleted in the latest merge.
> It's available in r624. I'm going to fix it now.
> Anyway, that menu is not specifically for this plugin, but is in
> common to all plugins. You should really see r624 :-D
>
> On Mon, Feb 15, 2010 at 3:15 PM, Jean-François Fortin Tam
> <email address hidden> wrote:
>> The name sounds fine to me. The configuration dialog could be improved
>> in terms of looks/spacing/etc., but I don't know how flexible that thing
>> is. At least, the following checkbox label:
>>
>>    Add the menu Plugins>Delete old tasks to manually delete them
>>
>> Should instead read:
>>
>>    Add the "Plugins > Delete old tasks" menu item
>>
>> Furthermore:
>> - the "Task Reaper Plugin configuration" label is redundant, it should
>> be in the window title instead of "gtg".
>> - it doesn't work, sadly... My tasks don't seem to be deleted, and there
>> is no "Plugins" menu at all. Don't know if this is to be expected.
>> - the option to add a menu item: shouldn't it go in the "Tasks" menu
>> instead of a (nonexistent) "Plugins" menu?
>> - the option to add a menu item... is it really necessary? Who would not
>> want that option anyway?
>>
>> --
>> cleanup feature
>> https://bugs.launchpad.net/bugs/495758
>> You received this bug notification because you are a bug assignee.
>>
>> Status in Getting Things GNOME!: Fix Committed
>>
>> Bug description:
>> I would like having an option to "Delete all done tasks", or maybe even an option to "Delete done tasks automatically after a week".
>>
>> Surely, keeping those hundreds of done tasks in the gtg db can't be good for performance.
>>
>>
>>
>

Changed in gtg:
milestone: 0.3 → 0.2.2
Changed in gtg:
status: Fix Committed → Fix Released
Revision history for this message
Jeff Fortin Tam (kiddo) wrote :

Bryce, to answer your initial question, this plugin has now made a very significant difference in terms of performance. This is the difference between a 15 seconds startup time on a netbook and a 7 seconds startup time (granted, I did not clean up my tasks before the existence of this plugin, so the filesize went down from 120 Kib to 56 Kib).

I hope the automatic/scheduled cleanup feature works as advertised :) and I'd somewhat have liked if it was turned on by default, but I guess this won't happen.

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.