[Kmymoney-devel] AccountsModel loadInstitution and loadSubaccounts recursiveness

[Cristian Oneţ]

On Tue, Sep 21, 2010 at 6:16 PM, Cristian Oneţ <onet.cristian at gmail.com> wrote:
> On Tue, Sep 21, 2010 at 6:06 PM, Alvaro Soliverez <asoliverez at kde.org> wrote:
>> On Mon, Sep 20, 2010 at 11:15 AM, Cristian Oneţ <onet.cristian at gmail.com> wrote:
>>> On Sun, Sep 19, 2010 at 4:44 PM, Alvaro Soliverez <asoliverez at kde.org> wrote:
>>>> Hello Cristian,
>>> Hi Alvaro,
>>>
>>>> I'm checking the results of the callgrind profiling.
>>>>
>>>> I've found some oddness.
>>>>
>>>> There are two methods in the AccountsModel that get called and incur
>>>> the most time, loadSubAccounts and loadInstitution.
>>>> The AccountModel::load() method calls both, but in turn, the
>>>> loadSubAccounts method calls loadInstitution too.
>>>>
>>>> I haven't looked at it in enough detail to verify if that's correct or
>>>> it can be avoided, because I was looking for something else.
>>>>
>>>> Could you look into it and check whether that's correct?
>>>
>>> Yes it is correct. The AccountModel::loadInstitution function creates
>>> the needed items in the model for the institutions view for each
>>> account (that is why it's called from load sub-accounts also). The
>>> best way to optimize the accounts model (and other parts of the
>>> application) would be to add more fine grained change signaling then
>>> the now existing dataChanged signal. So until we don't know what has
>>> changed we need to sync all the data between the model and the data
>>> storage and that takes time. I still need to take a look at this if we
>>> can gain some speed without doing the extra development of changing
>>> dataChanged but I think the time has come to do just that. Because
>>> that will be needed in the ledger also where for example everything is
>>> reloaded if the status of the transaction is changed.
>>>
>>
>> Is there any expensive calculation on the model, besides retrieving
>> the balance, which should be handled by the balance cache?
>
> Not that I know of. If rebuilding the account tree on each data
> changed is not expensive then it could be that the balance computation
> is and with the cache it can be improved.

After running some tests it seems that synchronizing the account tree
is the most expensive operation so adding the balance cache wont bring
big speed improvements in this area but a more fine grained data
change signal would. I will start to work on a patch that implements
this.

Regards,
Cristian