On Wed, 2010-02-24 at 09:59 -0500, Derek Atkins wrote: > Donald Allen <donaldcal...@gmail.com> writes: > > >> 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. > > For what it's worth, the old Postgres backend was dog slow too. > > I certainly encourage you to perform profiling to determine where our > bottlenecks are.
Another thing that I haven't done too much of is trying to add extra indexes or optimize queries. All SQL statements are logged to gnucash.trace. Feel free to add indexes and/or change queries to improve performance. In general, one major problem is that certain areas of the code just assume that the data is loaded. Until we remove those assumptions or provide alternatives, it seemed the safer route to just load all data at start time. Phil _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
