GNOME Bugzilla – Bug 722903
Poor performance of account hierarchy, budgets, reconcile window,...
Last modified: 2018-06-29 23:25:14 UTC
This bug is split of from bug 721822 and is focussed on the poor performance of the account hierarchy, budgets, reconcile window as reported in the former bug.
Comments taken from bug 721822: (Ian K) WinXp Pro SP3 32 bit. The UI is noticably slower on 2.6.0, particularly the main Accounts screen. Operations like resizing columns are very clunky and jerky. (Steven N) I can second this. I'm using Windows 7 64-bit. The main places I have noticed the UI slowness are the account list and the reconcile window. Resizing columns is especially excruciating. (Ian K) OK using a different (slower) machine with Windows 7 32 bit and an uncompressed data file (14.1MB now) I get the following: <snip> On this machine the UI was even worse - resizing columns almost impossible, and even getting a menu to drop down from the top (e.g. File menu) took a couple of attempts. The CPU wasn't working hard during the UI slowness, maybe GPU issues (this netbook has built-in graphics...) (Daniel) Switching from Accounts tab to Budget tab is also very slow, i.e. ~1.5s, rather than instantaneous.
To all that have explicitly experienced this slowness: are you all on Windows ?
I'm asking because I don't notice this at all on linux.
Further comments taken from bug 721822: (Frank) >gnucash --nofile 6:2014/01/24 00-23-40:gwen(25640):gui.c: 125: Using own callbacks in gui 0x22e0e60 Found Finance::Quote version 1.18 > but: >gnucash 6:2014/01/23 21-24-48:gwen(6745):gui.c: 125: Using own callbacks in gui 0x1ceaf50 Found Finance::Quote version 1.18 java version "1.7.0_45" OpenJDK Runtime Environment (IcedTea 2.4.3) (suse-24.9.1-x86_64) OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode) > I think loading a java engine could have some impact. (Geert) I don't know why suse loads a java vm at gnucash startup. This is not the case in Fedora and definitely not something added by gnucash. GnuCash doesn't use java. So the java issue should be investigated by the suse packagers (Frank) from http://lists.gnucash.org/logs/2014/01/2014-01-24.html#T11:13:41: <DimStar> fell_: gnucash uses webkit.. and webkit is stupid: it loads all plugins that are available... So the first opened report starts webkit and webkit loads the javaVM.
Frank you were just a tad faster than I was :) As I already replied in bug 721822: this issue is outside the scope of the performance comparisons between 2.4 and 2.6, because the same thing already happened in 2.4.
Windows 8.1 is also affected by this bug. Transitions in the UI for 2.6.1 are much slower than the ones in 2.4.13 (the last one I used). It happens when transitioning in the menu, double clicking accounts and in account hierarchy view. Sometimes the option within a menu do not show up at all.
GC 2.6.1 Windows 7 64 bit CPU i5 mem 4gb: I see this issue also. Sometimes takes 30 to 70 seconds to resize a column in account tree view. Interestingly, if you drag column edge, keep mouse button down, then wiggle mouse, takes only a couple is seconds. Seems like UI is not getting a chance to do its resizing work but wiggling mouse stops it from getting hung up. I may have a different setup to anybody else, in that I use single click instead of double click. Anybody else see this? I'll do some more testing tomorrow.
GC 2.6.1 Windows 7 64 bit CPU i5 mem 4gb: I see this issue also. Sometimes takes 30 to 70 seconds to resize a column in account tree view. Interestingly, if you drag column edge, keep mouse button down, then wiggle mouse, takes only a couple of seconds. Seems like UI is not getting a chance to do its resizing work but wiggling mouse stops it from getting hung up. I may have a different setup to anybody else, in that I use single click instead of double click. Anybody else see this? I'll do some more testing tomorrow.
Sorry about duplicate comment. Bugzilla doesn't work properly in Safari on iPad - committing a comment just hangs. I've done some more testing. Changing back to using Double click (Windows Explorer, Organize, Folder & Search options, General) makes no difference. What more info is required to get this out of status NEEDINFO? BTW, loading of data file is reasonably fast for me, approx. 20 seconds on i5, only a little slower than 2.4.11 on i7.
*** Bug 723712 has been marked as a duplicate of this bug. ***
From Bug 723712: Also MacOS is affected.
Just reading through the comments and noticed the mention in the logs of the call to Java. I'm on a Mac and I'm affected by the bug, however I do not have Java installed.
I've knocked off one contributor in df3d55c: Every call to local time was requiring a file access, so I made it cache the local TZ. That accounts for the bulk of the delay in the importer. File loading is slowed down mostly by the need to check all of the inputs for valid XML and UTF-8. That's unfortunately inherently slow, and it's made worse that the string has to be iterated over at least twice, once for UTF8 and again for XML. If bad UTF8 characters are found, they have to be substituted one at a time and the string re-submitted. If anyone knows of a fast way to handle this please share.
Win 7 64 bit GC 2.6.2 Accounts tab is slightly better. It seems to totally drop some column resize attempts. If you drag column edge, keep mouse button down, then wiggle mouse about, it still helps a lot.
2.6.2 is slightly better in my setup (Win 7 Enterprise 32bits). Menu transitions are still problematic.
I've now installed GC 2.6.2 on 2 x Win 7 i7 PCs and the problem is nearly non-existent (the previous PC I tried 2.6.2 on was an i5). There is still a small delay when resizing columns in the account tab, approx. 0.5 to 1.5 seconds, but not nearly as much of a problem. I guess there is still a problem as it should be instantaneous, even on an i5.
Unfortunately, the remaining major profiling issues are GList manipulation in the Account class and scheme-round-tripping in the GUI, both of which will require significant redesign to fix. Since that's planned for the next dev cycle, I think we have to accept that we've got what we're going to get from 2.6 and close this bug.
*** Bug 727300 has been marked as a duplicate of this bug. ***
(In reply to comment #17) > Unfortunately, the remaining major profiling issues are GList manipulation in > the Account class and scheme-round-tripping in the GUI, both of which will > require significant redesign to fix. Since that's planned for the next dev > cycle, I think we have to accept that we've got what we're going to get from > 2.6 and close this bug. John, you ran your profiling on OS X. Bug 723712 was explicitly created against that os. On the mailing lists I only hear Windows users complain about performance in gnucash 2.6.3. So it looks like your fixed have improved the performance on OS X (though feedback would be welcome on this assumption). Perhaps we should keep this bug open until we managed to do some profiling on Windows or can improve the performance on Windows again by other means.
The Windows problems seem mostly due to theme engine incompatibilities with Win8, while Gtk in general appears to have issues with Win8.1. ISTM neither of those is germane to this bug nor is there anything we can do about them short of dumping Gtk. My plan for resolving the GList speed issues is to replace all of them with c++ std:vector<>. Apropos to that, you might find this vid http://channel9.msdn.com/Events/Build/2014/2-661 of Herb Sutter's lecture at the M$ Build conference interesting: Around the middle there's a section on the performance of vectors vs. linked lists on modern multi-cache computers with prefetch. Really enlightening. Naturally, I'll do before and after profiles before actually committing anything.
About comment 20 and the Win8/Win8.1 thing; I run Windows 7 and I see performance problems with 2.6.x a lot.
*** Bug 729059 has been marked as a duplicate of this bug. ***
I have read reports on the mailing list that many of these performance issues were gone with gnucash 2.6.5. Can the people on this report report their findings please ? Thank you.
Testing GC 2.6.5 on Windows 7, i5 cpu, Accounts tab: Resizing column width by double click on column header vertical separator line: Always works, a little slow (0.5 to 1.5 seconds) Resizing column width by dragging column header vertical separator line: a little slow (0.5 to 1.5 seconds), often the resize request seems to be ignored or only partially actioned (ie if you try to grow a column by half an inch, it only grows by 1/8th inch) If you drag column edge to required width, keep mouse button down, then wiggle mouse about, column is resized as required. Overall 2.6.5 is about the same as 2.6.2 as far as I can see. Perfectly usable as I don't often resize columns in Accounts tab, and I know to use the wriggle mouse trick when I do. The long delays of 30 to 70 seconds to resize a column in account tree view has been gone since 2.6.2. It either works or not in a couple of seconds.
Using release 2.6.5 in Windows 7. CPU is Intel G630 running at 2.7 GHz. I have 6.0 Gig of RAM in this machine. I am not sure where to put this comment, but I will put it here. There are other functions that also are much slower than they used to be or are so slow that GnuCash appears to be frozen or hanging. One is the QIF import which is taking several minutes to import a file containing only 78 transactions in one account. This time I have several other programs open including Firefox, which is also a resource hog. The Windows resource monitor reports 77% memory used and very few hard faults at this time, but it also reports GnuCash is unresponsive, with 8 threads using 35% to 40% of the CPU. The other that I have observed is the transaction repair function, which literally runs all night both in windows and in Ubuntu 12.04 when started from the accounts window. The QIF import function occasionally comes up for air and updates the progress bar which is about 50% across after 20 or 30 minutes, but the repair function does not. The OFX import is actually faster in release 2.6.5 than it was in 2.4.13, taking one or two minutes to import 20 to 30 transactions.
Hi David, I see a G630 is a 64 bit pentium dual core with 4 threads. Please don't think I'm rude, I don't want to be, but, Does it run windows 7 Ok? I would have expected it to be generally slow... Regards, Chris
The G630 is only 3 years old. Yes, there are a lot of faster CPUs out there today, but it runs W7 fine with 6 Gig of Ram. I could put 8 Gig in this motherboard, but there are other things throttling this machine, like U-Verse giving me a whopping 3Mbps download speed for my money. I don't do multimedia or gaming with this machine, I check my email and run GnuCash. GnuCash doesn't multi-thread very well, especially the functions mentioned here, so more cores would just mean less interference from other programs, if they don't hog other resources too much. No other programs that I use come anywhere near GnuCash for slowness.
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=722903. Please continue processing the bug there and please update any external references or bookmarks.