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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Christian Stimming-4
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.

Regards,

Christian

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

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

John Ralls-2


> On Jun 24, 2018, at 11:48 AM, Christian Stimming <[hidden email]> 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
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

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

Robert Fewell-2
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 <[hidden email]> wrote:

>
>
> > On Jun 24, 2018, at 11:48 AM, Christian Stimming <[hidden email]>
> 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
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel