After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 722903 - Poor performance of account hierarchy, budgets, reconcile window,...
Poor performance of account hierarchy, budgets, reconcile window,...
Status: RESOLVED OBSOLETE
Product: GnuCash
Classification: Other
Component: User Interface General
2.6.0
Other All
: Normal normal
: ---
Assigned To: gnucash-ui-maint
gnucash-ui-maint
: 723712 727300 729059 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-01-24 12:32 UTC by Geert Janssens
Modified: 2018-06-29 23:25 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Geert Janssens 2014-01-24 12:32:46 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.
Comment 1 Geert Janssens 2014-01-24 12:38:58 UTC
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.
Comment 2 Geert Janssens 2014-01-24 12:43:16 UTC
To all that have explicitly experienced this slowness: are you all on Windows ?
Comment 3 Geert Janssens 2014-01-24 12:48:02 UTC
I'm asking because I don't notice this at all on linux.
Comment 4 Frank H. Ellenberger 2014-01-24 18:16:43 UTC
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.
Comment 5 Geert Janssens 2014-01-24 18:24:45 UTC
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.
Comment 6 Gilberto Reis Filho 2014-01-30 15:27:55 UTC
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.
Comment 7 Chris Good 2014-02-01 11:45:47 UTC
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.
Comment 8 Chris Good 2014-02-01 11:58:52 UTC
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.
Comment 9 Chris Good 2014-02-01 22:19:09 UTC
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.
Comment 10 John Ralls 2014-02-05 23:59:22 UTC
*** Bug 723712 has been marked as a duplicate of this bug. ***
Comment 11 Frank H. Ellenberger 2014-02-06 02:11:33 UTC
From Bug 723712: Also MacOS is affected.
Comment 12 vastphoto 2014-02-20 20:47:15 UTC
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.
Comment 13 John Ralls 2014-02-22 23:29:27 UTC
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.
Comment 14 Chris Good 2014-03-08 22:22:13 UTC
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.
Comment 15 Gilberto Reis Filho 2014-03-09 00:16:22 UTC
2.6.2 is slightly better in my setup (Win 7 Enterprise 32bits).

Menu transitions are still problematic.
Comment 16 Chris Good 2014-03-16 03:55:07 UTC
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.
Comment 17 John Ralls 2014-03-16 18:20:16 UTC
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.
Comment 18 Geert Janssens 2014-04-02 09:42:57 UTC
*** Bug 727300 has been marked as a duplicate of this bug. ***
Comment 19 Geert Janssens 2014-04-24 13:04:13 UTC
(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.
Comment 20 John Ralls 2014-04-24 20:14:50 UTC
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.
Comment 21 Fredrik Persson 2014-04-25 05:10:21 UTC
About comment 20 and the Win8/Win8.1 thing; I run Windows 7 and I see performance problems with 2.6.x a lot.
Comment 22 Geert Janssens 2014-04-27 15:47:57 UTC
*** Bug 729059 has been marked as a duplicate of this bug. ***
Comment 23 Geert Janssens 2015-02-10 21:41:08 UTC
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.
Comment 24 Chris Good 2015-02-14 21:19:32 UTC
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.
Comment 25 David Carlson 2015-02-16 23:00:00 UTC
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.
Comment 26 Chris Good 2015-02-17 07:09:03 UTC
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
Comment 27 David Carlson 2015-02-17 08:21:38 UTC
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.
Comment 28 John Ralls 2018-06-29 23:25:14 UTC
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.