[Kmymoney-devel] AccountsModel loadInstitution and loadSubaccounts recursiveness

[Alvaro Soliverez]

On Sat, Sep 25, 2010 at 9:41 AM, Cristian Oneţ <onet.cristian at gmail.com> wrote:
> 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.
>

What does this synchronizing do? Can you handle it with a signal which
is only emmited when an account is added/modified/rdeleted?