SQL backend performance

Donald Allen donaldcallen at gmail.com
Wed Feb 24 08:06:19 EST 2010

On Tue, Feb 23, 2010 at 11:40 AM, Geert Janssens
<janssens-geert at telenet.be> wrote:
> On Tuesday 23 February 2010, Donald Allen wrote:
>> On Tue, Feb 23, 2010 at 9:15 AM, Geert Janssens
>> > Your assumptions on how things work are correct.
>> >
>> > And I noticed this performance decrease as well.
>> >
>> > There is one difference between the xml and the sql backends that may
>> > influence this (at least in part): the sql backend writes lots of debug
>> > information to gnucash.trace at present. I don't know how much impact
>> > this has, I haven't tested without debug information, but if we disable
>> > the debug information before the 2.4 release, it will surely narrow the
>> > gap.
>> I'm seeing trace files on the order of .5 Mb. As I mentioned earlier,
>> saving my xml file takes about 2 seconds. It's about 2.5 Mb (over 20
>> Mb uncompressed) and the 2 seconds includes the time to compress it.
>> Writing the trace file is not nearly as hard a job and the periodic
>> writes should be to the buffer cache on any reasonable machine. So
>> I'll guess (again) that the gap-narrowing won't amount to much. I hope
>> I'm wrong :-)
> I think true measurements will be the only way to find out what causes delays
> where.

Of course. I spent a big chunk of my career doing performance analysis
on various bits of complicated software and learned very young (the
hard way) that if you think you know how your software behaves and
where the time is going, you are probably wrong. Measurement, done
correctly, is the only way to get to the truth reliably. I sometimes
had to insist on measurement by people who worked for me who were as
cocky (and wrong) as I was when I was young :-)

But until the measurements are done, there's no harm in doing some
educated guessing, so long as the guessing doesn't replace the
measuring. If you are frequently right, it can help you set your
measurement priorities. If you are frequently wrong, it reminds you
that you aren't too good at modeling the behavior of software in your


 But it's clear there's still room for performance improvements.
> Geert

More information about the gnucash-devel mailing list