generating reports takes minutes

Thomas John Vitolo tjvitolo at bu.edu
Wed Nov 1 12:02:27 EST 2006


Quoting Derek Atkins <warlord at MIT.EDU>:

> Hi,
> 
> Quoting Thomas John Vitolo <tjvitolo at bu.edu>:
> 
> > Regarding the generation of reports being so slow...
> >
> > For an "average" user, which is the bottleneck -- the aggregation
> of 
> > data or the
> > instructions to draw the charts?  If it's the former, I have a 
> > follow-up question:
> >
> >
> >
> > A chart of data is useful because it aggregates many data points
> into just a
> > few.  A pie chart with 10 slices has:
> > 1 Title
> > 1 Date range
> > 10 slice sizes (or equivalently, values)
> > 10 slice names
> >
> > So, when I close gnucash, why doesn't it "cache" the data of the 
> > charts, so it
> > doesn't have to re-calculate the data when I re-open.  This way,
> the time to
> > re-calculate the data is avoided, and I can open gnucash much more
> quickly.
> > Many times, I don't care about viewing the charts, I just want to
> add some
> > transactions by hand, and I hate that I too have to wait minutes
> for 
> > my reports
> > to be generated.
> >
> > So, where's the bottleneck?  If it's aggregating the data, why not
> 
> > cache it, so
> > the user has more control over load times?
> 
> The open reports are defined per-user.  Your datafile could be
> shared
> amongst multiple users.  Also, you could have added additional data
> (e.g. pricedb entries) between runs of the gnucash GUI.  This is
> why
> the data cannot be cached, because it might have changed between
> times
> that you, personally, run gnucash.

But so what?  It's true that a user could add data that was dated prior to the
"end date" of a report, but it wouldn't be hard to include a binary indicator:
data has changed since this report generated, or not.

For me at least, the charts are extremely useful, but not every time I use
gnucash.  In fact, they're useful maybe 1 in 10 times.  The other 9 times all I
want to do is add data, and it's foolish for me to have to wait a few seconds
for my accounts to be loaded and then minutes for the charts to be created, when
all I want to do is manipulate the data in the accounts.

After all, the charts don't automatically get re-generated every time I change
data in an account, so why should they be re-generated every time I open
gnucash?  Conceptually, there's no reason to "believe" the charts are accurate
if the gnucash application is open, since the data may have changed and the
charts not reloaded.  So, why should this be different when I open the application?


P.S. I do run gnucash locally.  As for the bottleneck time, either I wasn't
clear with my question or my understanding isn't clear.  The "Accounts" tab
loads in a few seconds, but the charts take minutes.  It seems to me that the
requirements for generating a chart are (1) to aggregate the appropriate subset
of the "Accounts" data necessary for that particular chart, and then (2) the GUI
to actually draw the charts.  I wonder how much time is spent in (1) and (2) for
any given plot.  If most of the time is spent in (2), than my proposal doesn't
help anyway.  If, however, most of the time is spent in (1), which I suspect to
be the case as users generate more data, than my proposal of "caching" the data
would substantially improve the time required to open the application, at the
cost of initially generating plots that aren't known to be correct (which is the
case at any other time when the application is open, since the data may have
been changed by the user but the plots haven't yet been manually reloaded by the
user).


 - stomv

> As for where the bottleneck is...  I dont know.  You could copy
> your
> datafile to another name and time how long it takes to open.  This
> would give you the baseline for the application load and data load
> process for your particular machine.  Compare that to the amount of
> time it takes to load the reports as well.  Then you'll have a clue
> about where to start looking.
> 
> Finally, are you running gnucash locally or across remote-X?  The
> latter
> is known to be HORRIBLY slow.
> 


More information about the gnucash-user mailing list