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

[Robert Fewell]

Just wondering the following...

Are the imported transactions related to the open registers ?
If you created a new register with a blank transaction, do you see the same
delay, just thinking less to draw ?
Not sure if you have open aqbanking windows/dialogs open that are covering
the register, if you have space can they be moved so there is nothing
covering the main Gnucash window, does this make a differnce.
If you do have windows/dialogs covering, what type are they, proper windows
or dialogs with transient parents, might make a difference.

Bob

On 24 June 2018 at 22:00, John Ralls <jralls at ceridwen.us> wrote:

>
>
> > 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
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>