gnucash 1.4.9 slow.

Bill Gribble grib@linuxdevel.com
Tue, 10 Jul 2001 13:29:08 -0500


On Tue, Jul 10, 2001 at 02:03:41PM -0400, Stuart D. Gathman wrote:
> I have Gnucash 1.4.8 supplied with Ximiam Gnome on RH6.2 kernel 2.2.19.

This is an outdated version.  1.6.1 is the current stable release of
gnucash and performs substantially better.

> However, gnucash uses 60M(!) of RAM according to top with my accounts
> loaded.  Deleting one transaction takes 15 seconds.  Moving the
> transaction cursor forward or backward takes 15 seconds with the "auto
> split" feature on.  Opening a split takes 15 seconds without the "auto"
> feature (but scrolling is reasonable).

These are much faster in 1.6.1, thanks to improvements in the 
register by Dave Peticolas. 

> If the transaction engine is the problem (as I am guessing from the slow
> delete), I might try to create an ISAM based alternative.  (SQL requires
> too much admin for personal accounting.)

Well, the SQL approach has the advantage that it's already done in the
1.6 series :) At the moment it has a little bit of extra setup, but
that will be diminished as time goes on.  All of the database setup
and initialization can be automated with sufficient patience.

It would be a good exercise to create a flat-database backend, and
would be of benefit to a lot of people if you want to tackle it.  The
current XML backend is more of an "import/export" format than anything
else, and the current SQL backend has a lot of get-it-done-quick
hacks.  By the time you finished generalizing the Backend
infrastructure to allow another database backend I'm sure the SQL
backend (which is probably going to see the most development over the
next 6 months) will be a lot better for it.

> Naturally, Quicken classes would need to be translated to Gnucash
> actions if you go this route.

Gnucash supports but doesn't have a GUI for arbitrary tags attached to
transactions.  Some time in the 1.6 series, the QIF importer will
translate QIF classes into Gnucash tags.  This will allow you to
attach any number of tags to splits and transactions, and reports
should be generalized to allow things to be narrowed by tags.

The Action field is not much more than a fossil at this point.  It's
almost useless the way it's designed but can't be eliminated because
some people are using it :(

> I also use CheckFree and don't want to give it up.  :-)

We (Linux Developers Group) are talking to Checkfree about this.  It
may be something that can only be accessed via a registered account on
our website (from within Gnucash), because Checkfree wants
accountability.

> I would love to write reports for GnuCash, but I am afraid I can't
> handle the current Scheme syntax.  Did I hear rumors that Guile will
> be offering an alternate syntax?

It's possible that an alternate Guile syntax will be available in the
future, and if it is it will work with Gnucash.  It's not in the
immediate future.  We are also looking at KDE's Kugar reporting
language as a limited-functionality way of writing simple kinds of
reports.  It's XML-based.

> [LISP - Lots of Irrational Silly Parenthesis] :-)

Most of the Gnucash developers are experienced Scheme/LISP programmers
who like the syntax of those languages.  This joke is very old and
tiresome and not likely to make people want to help you :)

Thanks,
Bill Gribble