Re: guile performance too slow for gnucash?

[Rob Browning]

"Neil W. Van Dyke" <address@hidden> writes:

> Your comments about Guile performance problems in GnuCash have made
> me uneasy.  Are you trying to do real-time predictive models for
> automated trading, or data-mining 3-D visualizations, or something? :)

Yes :>

Seriously, most of the time Guile is plenty fast, and most things we
do, the human is by far the slowest bit.  However, there are cases
where performance is an issue.  Mostly this is where we're trying to
massage a lot of data, either to import all of a user's QIF data
(which requires a *lot* of pattern matching, and
cross-structure-checking, to try and guess what the QIF really meant
-- it's a frightfully lame format), or to generate reports from the
user's data.  In the report generation case the real effort is in
processing a hierarchical (stack based), context-sensitive, html style
system, so there's a lot of "looking up the stack" to figure out what
tags to generate for the given table-cell or whatever, depending on
the current cell's place in a nesting order.  This results in a lot of
chained hash-refs, more or less, though it's somewhat more complex
than that.

My experience is that as interpreters go, Guile's pretty fast, but
with a suitable byte-code generator (i.e. the VM people have been
discussing), just-in-time compiler (Lightning), or off(psuedo-on)-line
compiler (hobbit), I suspect guile can be *much* faster.  In gnucash,
I don't think we really need to compile all our code, but there are
some bits that should almost certainly benefit dramatically, and
halving or quartering the time someone has to stare at the QIF
processing dialog, or making the system respond instantly when you
click on a link, will be really nice.

> So far, pure Guile seems acceptably fast for my first substantial Guile
> application (which is bound by speed of its network link and remote
> servers, not by Guile), the I/O seems to work well, the VM footprint
> appears relatively small and leak-free, I haven't noticed any serious
> bugs, etc.

It sounds like you're going to be fine with Guile.  You can always
migrate bits over to C that really have to be fast (and Guile isn't
cutting it), and if we make substantial progress on the VM, JIT, or
hobbit fronts, then you can take advantage of those too.

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930