[Kmymoney-devel] Is there a cache for accounts balance?

[Fernando Vilas]

On Sunday, September 05, 2010 10:50:58 Alvaro Soliverez wrote:
> On Sun, Aug 29, 2010 at 5:09 PM, Fernando Vilas <fvilas at iname.com> wrote:
> > On Sunday, August 29, 2010 11:10:46 Thomas Baumgart wrote:
> >> Hi,
> >> 
> >> on Sunday 29 August 2010 16:24:30 Alvaro Soliverez wrote:
> >> > Hello all,
> >> > I've been doing some callgrind tests to check the startup performance.
> >> > One thing I noticed is that almost a 10% of the time is spent
> >> > calculating balances.
> >> > For a normal start, balances are needed by forecast, reports and the
> >> > home
> >> > 
> >> >  view.
> >> > 
> >> > Do you think it would be worth to cache the balance data on
> >> > MyMoneyFile?
> >> 
> >> That's already done. Once the XML file is loaded, the method
> >> MyMoneySeqAccessMgr::rebuildAccountBalances() is called which caches the
> >> balance with each MyMoneyAccount object.
> >> 
> >> Also, MyMoneySeqAccessMgr::balance() maintains a cache.
> >> 
> >> The problem is, that you cannot cache 'the' balance of an account, as it
> >> may be different for each date.
> > 
> > There was something similar in the DB backend, but I removed it some time
> > ago when trying to debug account balance inconsistencies.
> > 
> > I think we should move the balance cache from the backends into the
> > MMFile object, so we have a common cache. As Thomas says, it also needs
> > to handle multiple dates.
> 
> The cache of course should be per account, per date. As there is not a
> single balance per account.
> On a similar note, forecast performance might be improved if I change
> it from requesting a balance in the past and calculating the balance
> forward, to requesting the current balance, and calculate the past
> balances backward. At least for the historic method, I think that
> might result in a performance improvement.

Is there any opposition to moving this to the MyMoneyFile layer? If not, I 
will sign up to implement it before the January feature freeze.

-- 
Thanks,
Fernando Vilas
fvilas at iname.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kmymoney-devel/attachments/20100909/149be382/attachment.sig