gtg-contributors team mailing list archive

[Izidor Matušov <izidor.matusov@xxxxxxxxx>]

Hi all,

I spent this forenoon by profiling and hacking GTG & liblarch. I would 
like to share my results.

I did the profiling with these caveat:
  * I run the current trunk, rev 1125
  * my test data were my real data: 392 active tasks, 432 tasks total, 
40 tags, each with color, some of them are stacked, no saved search
  * I measured time with my android phone based on the following metric:
    * start ./scripts/debug.sh
    * click 'start timing' on the phone
    * wait until all tasks are loaded and/or activity of processor is 
zero in system monitor
    * click 'stop timing' on the phone

(I know, accuracy is horrible. However, I am talking about of a 
magnitude of seconds what is acceptable. Yes, I was to lazy to fix 
Default backend loaded signal)

Results:
========

Normal start, rev 1117 => 90 seconds, "state of the art" ;)

Other are based on modified rev 1125, with applied performance patch 
which speed up boot for 10 seconds, rev 1124.

Normal start => 80 seconds

A simple patch for basic caching of tag counts (hacked this morning) => 
70 seconds

With disabled tag counts (it means without any usable tag sidebar) => 
*28 seconds*

Without tag counts and without title bar update => about 27 seconds (not 
significant change)

With processing every item in queue at once, without tag counts and 
without title bar update => about *5 seconds*, UI freezes

*connecting to liblarch after 2 seconds*, without counting and title bar 
update => about *7 seconds*, UI is white, looks like something bad has 
happened for a while

with processing every item in queue at once, with connecting to liblarch 
after 2 seconds, without counting and title bar update =>  about _* 2 
seconds *_ !!! (UI is not usable during load...)


BTW: Given those conditions, it takes about 1.64 seconds to switch from 
WorkView to normal mode.  I think we hit the current limits of filling 
and drawing TreeWidget! (That can be optimized later)

What does it mean?
==================

1, We need to rework liblarch tag counting! Having effective structure 
for counting is needed.
2, We might think about redesign of basic backends concepts (ehm... 
synchronization services, sorry Radina ;)
  * making default backend during the load synchronous because we need 
local cache... We probably need to redesign that concept. I will talk 
about it to you GTG geeks later.
3, Don't show GTG window and don't connect TreeWidgets until the default 
backend is loaded. It would mean:
   * when you see the main window, you can work with tasks
   * you might wait about 3-4 seconds with quite big task lists until 
GTG starts. To be honest, my firefox needs about 5-6 seconds to load 
from HDD to memory. Until everybody has SSD, it would be acceptable.
   * if you have really really really big task list, it could take 
really long to load your tasks and show the first window. I guess the 
limit would be about 2000 tasks (just guess, no measurements yet) We 
then might want to show at least a progress bar ;)

When will it be?
================

We need to redesign the concept of localfile backend. It was designed by 
Luca for quite different GTG. It will take some time to discuss it. I 
also need to write down my own GSoC application (even more cool features 
for GTG!). In other words, it would take few weeks.


Credits
=======

Federico, thanks for the idea of not connecting treemodel immediately to 
liblarch.

See you later!

Izidor