performance test

I've committed a few changes to gtg trunk for this bug. Revision 858 adds a -b flag to gtg and to debug.sh which causes gtg to exit as soon as its finished initialization; this permits profiling boot-up time. It's intended that this be used in conjunction with debug.sh's -p and -s flags, but not required.

There is a data set in test/data/bryce which has many tasks in it (anonymized), which I think covers part of what this bug needs. It can be used with debug.sh via the -s flag. For instance:

  scripts/debug.sh -b -p -s bryce

That will do a profile of the initialization time when loading the 'bryce' dataset.

Due to a lot of work done by lionel in past months, I think the need to test the set of commits following the Big Refactorization is unnecessary now. Indeed, performance of gtg trunk at the moment is quite good compared with 0.2. But certainly there is still room to improve (and plenty of room to regress!) so having performance tests (and graphs) is still important.

Part of the original bug report called for being able to test 'with a filter applied'. I attempted to add a -t <tag> flag to gtg which would cause it to start up with a particular tag pre-selected. (It sounded like it could be marginally useful beyond this testing.) However my efforts were frustrated by trying to get TreeView to do what I wanted; I could get it to select the 'All tasks' or 'Tasks without tags' items in the tag sidebar, but never any of the tags.

I'm not even sure if this is what Lionel meant by 'with filter applied' or if there'd be an easier way to achieve it. So I've decided to not pursue this line of development further, at least not for now.

I even think the performance with filters is actually not that bad (still worth having a test for!)

Some areas that where gtg does appear to need some performance tuning attention:

1. When lots of taskeditor windows are visible (esp. if they have substantial text in them) it seems gtg gets bogged down.

2. Operations on a selection of tasks. For instance, select 20 tasks and reschedule them for tomorrow; it can take a noticeable amount of time (10 sec? not sure).

3. Toggling WorkView off, when there are lots of tasks with start_dates in the future.

For helping to debug #1, I added a parameter to gtg_stress_test that allows adding random text to tasks. So you can do something like:

1. scripts/debug.sh
2. scripts/gtg_stress_test 1 10000

which adds one task with 10,000 words. Now try resizing the task browser. Oomph!

If you want to really thrash your system, try: gtg_stress_test 10 10000
Warning: be prepared to kill -9 gtg!

Now, it would be interesting to be able to use both debug.sh and gtg_stress_test together. It'd be interesting to start up an empty gtg, add bunches of tasks, and then close it. Then see how long it takes and profile where it is slowest.

I think we have several tools to gauge the performance of GTG now. Closing the bug, as it's quite general.