Any tips to improve performance?
plongstaff at rogers.com
Tue Dec 29 11:26:41 EST 2009
On Tue, 2009-12-29 at 10:42 -0500, Derek Atkins wrote:
> Phil Longstaff <plongstaff at rogers.com> writes:
> > Many of the reports work by querying the engine for a set of splits matching a
> > specific filter, then looping and adding the values (all in scheme). Once the
> > database backend is released in 2.4, this can be changed to a single SQL
> > query.
> > Some preparation for this could begin by adding an appropriate API to the
> > engine (Account?) which takes a QofQuery for splits and returns the sum of the
> > splits. This at least creates the abstraction needed by the scheme code which
> > can be replaced.
> Note that in general the scheme functions are not returning a single
> gnc_numeric total, but rather a list of <gnc_commodity,gnc_numeric>
> tuples that sum up the amounts in each commodity. Also note that
> different reports are going to want to perform different types of
> currency conversions based on different requirements. For example, for
> Income and Expense accounts you probably want to compute an exchange
> rate based on the date of the transaction instead of the date of the
> report, whereas Asset and Liabilities most likely want to compute
> exchange rates based on the report date.
Yes, exchange rates do throw a kink into it.
> But yes, implementing some of this in C could possibly help improve
> I'm not sure a SQL statement would work, because it sounds like 2.4 will
> still default to XML, so the reports cannot (and should not) depend on
> the use of SQL in the backend.
The scheme code wouldn't want to know about the backend. However,
somewhere (Account? backend?), there should be a "get me the amount on
a certain date" or "get me the amount according to a query" function
which with an XML backend would filter and sum, and with an SQL backend
would do an SQL query so that the SQL engine would filter and sum.
More information about the gnucash-devel