[GNC-dev] Slow user interface in 3.x gnucash: Online transaction import painfully slow - with workaround

[John Ralls]

> On Jun 24, 2018, at 11:48 AM, Christian Stimming <christian at cstimming.de> wrote:
> 
> Dear developers,
> 
> as I'm still in the process of migrating my everyday work from 2.6.x gnucash 
> to 3.x gnucash, I enountered some places where the user interface is still 
> quite slow in current 3.x gnucash compared to the old one. I've fixed on such 
> issue in the last days, but other remain.
> 
> One such place that seems painfully slow is the online transaction import 
> (using aqbanking with a German HBCI bank account). After the connection log 
> window closes, it took literally minutes until the transaction-matching window 
> appeared. During this step, the imported transactions should be matched 
> against potentially existing ones with the identical online_id, and suggested 
> matches for all the non-matching ones are being calculated. (After editing 
> normally there, clicking "Ok" was additionally very slow, but let's focus on 
> the first step.)
> 
> By looking into this with valgrind/callgrind, it turns out that the register 
> windows keep getting refreshed a lot, i.e. gtk_widget_draw is called several 
> ten thousands times during this phase. This is quite weird. Of course the UI 
> shouldn't get updated during the calculation step, and only after this is 
> finished the UI update should be activated again.
> 
> Here's the workaround: I closed all account register windows, and select the 
> online actions by selecting my online account in the account tree widget as 
> selected item. When calling the online transaction download now, there is no 
> large delay anymore! (i.e. the behaviour is practically identical to 2.6 
> gnucash)
> 
> This seems quite weird to me. It seems there is no gnc_suspend_gui_refresh / 
> gnc_resume_gui_refresh pair for this first step before the matcher window 
> opens, so maybe this needs to be inserted in the correct place. However, in 
> 2.6 gnucash this was missing, too, and it didn't seem to be a problem.
> 
> Also, on clicking "Ok" there is such a suspend/resume pair (in import-main-
> matcher.c lines 160ff), unchanged from 2.6 to now, but in my first tests when 
> the register windows are open, this step has just as well a minute-long delay 
> similar to the first step.
> 
> Anyone an idea on what might be missing? Thanks for pointers. 
> 
> Unfortunately I didn't find an easy method to reproduce this without online 
> account. Maybe some of the file imports show this as well, but so far I didn't 
> encounter it except with the online account.

Christian,

I suspect this is https://bugzilla.gnome.org/show_bug.cgi?id=792986 that Mechtilde reported several months ago. She wasn't able to provide any additional data and none of the rest of us have the requisite bank account to be able to reproduce the issue.

There are two prime suspects here: One is that the redraw code is different between Gtk3 and Gtk2 with the former being significantly slower and possibly incompatible with gnc_suspend_gui_refresh; the other that the change of the register redraw code from libgnomecanvas to directly to a cairo surface, being lower-level code is inefficient.

Regards,
John Ralls