testing the book zeroing code (maybe for backport?) <<Offline>>

Derek Atkins warlord at MIT.EDU
Thu Feb 7 16:37:35 EST 2008

Mike or Penny Novack <stepbystepfarm at mtdata.com> writes:

>>Wow!  I didn't think my algorithms were THAT bad!  Okay, I'll
>>see about adding a progress dialog..  Unless someone else
>>can get to it first.  I probably wont have time for a bit.
> Derek,
>    Would you want me to take a look? Lot's of experience "tuning"
> including redesigning of unwise choices for algorithms.

Sure!  Go for it!

>    Might not be your fault at all. I haven't yet looked at how GnuCash
> does anything and the question here might be just  how the data for an
> account is stored. It shouldn't take MUCH longer to generate the two
> closing transactions than it does to calculate the balance of each
> income and expense account. But if GnuCash does not store the balances
> (recalculated each time by examining every transaction in each such
> account) then your time might not be excessive. Might be quite
> reasonable.

Well, it's possible that GetBalanceAsOfDate goes forward in time
instead of backwards in time, which means that the more transactions
you have the longer it takes.

>    There are exisiting things which you could use for comparison. For
> example, the time required to produce an Income/Exense report or a
> trial balance or ....... (anything that requires obtaining the balance
> of each account as of some specified date). You could ask your testers
> to give you the time one of these things took. No point looking for
> what might be wrong with your "closing" until you KNOW something is
> wrong (takes MUCH longer than one of these).


> Michael


       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available

More information about the gnucash-devel mailing list