On Tue, Feb 23, 2010 at 11:40 AM, Geert Janssens <janssens-ge...@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 head. /Don But it's clear there's still room for performance improvements. > > Geert > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
