gtg-contributors team mailing list archive

[Lionel Dricot <ploum@xxxxxxxxx>]

On Sat, 27 Feb 2010 16:04:07 -0800, Bryce Harrington <bryce@xxxxxxxxxxxxx>
wrote:
> 
> For testing purposes, I created a couple data sets which can be
> imported to help stress test gtg:
> 
>  1. Go to Edit > Preferences > Plugins.  Check Import from JSON.
>  2. Plugins > Import from JSON
>  3. Enter one of these URLs:
>     + http://bryceharrington.org/files/tasks_200.json
>     + http://bryceharrington.org/files/tasks_2000.json
> 
> The first loads ~200 tasks (actually more like 150 I guess), the second
> loads over 2000 tasks.
> 
> I've found the first one loads quite quickly, the second one takes a
> minute or two to load.
> 
> With only the first loaded, the gtg UI is nicely responsive and quite
> snappy.  I tagged bunches of tasks, marked 200 done at once, scrolled
> around a lot, and the app was extremely responsive.
> 
> With the second loaded, the UI is quite sluggish until it has finished
> processing all the new bugs (looks like it's saving them).  But after
> that the UI is again impressively responsive.  Applying tag 'foobar' to
> all 2000 tasks takes about a minute during which time the interface is
> frozen, but it comes back fine without crashing.

This is really interesting. Well, I guess that a lot of the time is spent
opening the xml file and writing it (at least once for each time). I
suspect that we are doing it a bit too much.

I'm really interested in optimisation. Now that we have done a good step
in the right direction, I think we should concentrate on non-destructive
optimisation. It means that we should concentrate on optimisation that
don't change at all the behaviour of GTG.

Bertrand was proposing to not use anymore the cleanxml formatting. While
it's a good idea, this is "destructive" optimisation (the behvaiour
changes) and I would prefer to avoid it during the whole 0.3 developement
process and do as much as we can.

I've already found out that, when you open a task, it is saved twice !!!


The 2000 tasks usecase is very useful, thanks Bryce :-)

Lionel