GNOME Bugzilla – Bug 643586
Time to load program and open database has doubled in 2.4.3
Last modified: 2018-06-29 22:54:28 UTC
I installed 2.4.3 on my Windows 7 SP1 system (32 bit). My database is in MySQL. The time required to load the program and open the database arriving at the register screen has more than doubled from version 2.4.0. Time: 2.4.3 2.4.0 To User/PW prompt :11 :12 To register screen :48 :21 Times were taken with a stop watch. Test was done 3 times for each version with the results from the first load discarded as it usually takes longer since Windows does not have as much in cache. The 2 and 3 times were approximately the same and are shown above. I suggested the component for this bug as being the SQL Backend but that is speculation on my part. I made this guess based on the fact that 2.4.2 crashed trying to open MySQL and that perhaps the fix has slowed things down.
I have similar issues with Sqlite data file. It has become MUCH slower to open the Sqlite data file from 2.4.0 to 2.4.3. File > Open with 2.4.0 takes about 1 second. The same operation with 2.4.3 on the same file takes about 20 seconds. It seems the bigger the file the slower. Playing around with a new empty file and it opens fast. My 'live' file is about 950KB (quite small), and growing by about 10KB per day, so the concern is that it will eventually get impossibly slow to open.
During this delay opening the file, the process gnucash.exe is using large amounts of cpu. Windows XP 32bit.
This has gotten even slower with 2.4.5. My Sqlite date file (now 1.4MB) takes about 35 seconds to load on 2.4.5. The same file with 2.4.4 was taking about 30 seconds. If I save as XML and open that it opens almost instantly.
This is interesting, and perhaps an MSWindows problem: I just tested with my 21MB primary accounts SQLite3 file and found that it took 16 seconds on both 2.4.0 and 2.4.5 on a MacPro 2.8GHZ. (Gnucash is single-threaded, so the 4 cores don't add anything). There haven't been any backend changes that would cause a slowdown in loading since December; the only change was the int64 round trip test to check for the libdbi bug, which isn't likely to make a difference -- it consists of a creating a temporary table and a single write and a single read to that table, then comparing the results of 4 fields. It shouldn't take more than a microsecond or two with SQLite3. It could take longer on a server connection over a network depending on the latency, but even then should be on the order of a millisecond as long as the server is local. (That check was what caused the crash in 2.4.2 on MSWin machines.)
triage: I think this and a few other SQL backend issues are now redundant
Thanks for taking the time to report this. However, you are using a version that is too old and not supported anymore by GnuCash developers. GnuCash developers are no longer working on that version, so unfortunately there will not be any bug fixes by GnuCash developers for the version that you use. By upgrading to a newer version of GnuCash you could receive bug fixes and new functionality. Please feel free to reopen this bug report if the problem still occurs with a recent version of GnuCash, or feel free to report this bug in the bug tracking system of your Linux distribution if your distribution still supports the version that you are using.
Reassign version to 2.4.x so that individual 2.4 versions can be retired.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=643586. Please update any external references or bookmarks.