edit/modify transaction box takes >10 sec. to open

[Steve Sibelman]

(on Windows 7) With version 4.5.x, opening the edit transaction dialog box was a bit slow -- a few seconds. With 5.0.0, the delay is much longer -- over 10 seconds (installed app or portable). This is annoying to make me retreat to 4.5.x in spite of other improvements.

HomeBank is an excellent tool that I greatly value. Merci beaucoup! Saying this "out loud" makes me realize it was long past time to donate some euros, not just wish/bug reports, to the wonderful work of M. Doyen. Now I've done that, which will naturally give this bug report high priority ;-)

[Maxime DOYEN (mdoyen)]

Ok, here is a debug version of next release v5.0.1 wich is still on rc state for now.
Unzip it and test your file with it (BUT DO NOT SAVE YOUR FILE WITH THIS version).
I activated the debug of every process in that area, please track on what line the console stop and do heavy things.

please alos provide you file metrics (menu tools / file statistics)

[Maxime DOYEN (mdoyen)]

You can also anonimyze your file and send it to the contact email mentionned here:
http://homebank.free.fr/support.php

[Steve Sibelman (sib-g)]

Bon jour.

I copied the executable you sent into my 5.0 folder. This version also
shows the ~10sec. load time for the transaction modify/edit window.

Console shows many instances of this error:
** (HomeBank_debug.exe:4076): WARNING **: txn consistency: fixed invalid
cat on split txn

Probably I have a problem due to errors in my database cleanup efforts
(with vi and my own C code). I will hunt for a missing category, esp.
in my numerous split transactions. I will let you know when I have
investigated further.

File metrics:

Cheers,

Steve S.

On 3/29/2015 12:06 PM, Maxime Doyen wrote:
> Ok, here is a debug version of next release v5.0.1 wich is still on rc state for now.
> Unzip it and test your file with it (BUT DO NOT SAVE YOUR FILE WITH THIS version).
> I activated the debug of every process in that area, please track on what line the console stop and do heavy things.
>
> please alos provide you file metrics (menu tools / file statistics)
>
> ** Attachment added: "HomeBank_debug.zip"
> https://bugs.launchpad.net/homebank/+bug/1437883/+attachment/4360115/+files/HomeBank_debug.zip
>

[Steve Sibelman (sib-g)]

Further study shows the "fixed invalid cat on split txn" warnings are
caused by the presence of a superfluous transaction-wide category value,
in addition to the necessary scat="....." data.

The debug output has other, more interesting information (see attached).

-------- Original Message --------
Subject: Re: [Bug 1437883] Re: edit/modify transaction box takes >10
sec. to open
Date: Sun, 29 Mar 2015 14:31:26 -0700
From: Sibelmans <email address hidden>
Reply-To: <email address hidden>
To: Bug 1437883 <email address hidden>

Bon jour.

I copied the executable you sent into my 5.0 folder. This version also
shows the ~10sec. load time for the transaction modify/edit window.

Console shows many instances of this error:
** (HomeBank_debug.exe:4076): WARNING **: txn consistency: fixed invalid
cat on split txn

Probably I have a problem due to errors in my database cleanup efforts
(with vi and my own C code). I will hunt for a missing category, esp.
in my numerous split transactions. I will let you know when I have
investigated further.

File metrics:

Cheers,

Steve S.

On 3/29/2015 12:06 PM, Maxime Doyen wrote:
> Ok, here is a debug version of next release v5.0.1 wich is still on rc state for now.
> Unzip it and test your file with it (BUT DO NOT SAVE YOUR FILE WITH THIS version).
> I activated the debug of every process in that area, please track on what line the console stop and do heavy things.
>
> please alos provide you file metrics (menu tools / file statistics)
>
> ** Attachment added: "HomeBank_debug.zip"
> https://bugs.launchpad.net/homebank/+bug/1437883/+attachment/4360115/+files/HomeBank_debug.zip
>

[Steve Sibelman (sib-g)]

File metrics: account 15 transaction 15266 payee 3587 category 69
assignment 42

Testing with hacked .xhb files shows the giant payee list is the
problem! I've worked to reduce this (was ~5000) by eliminating
duplicates caused by years of poor Quicken behavior.

I'm not sure why homebank code needs to process all payees to enter
transaction edit. I would imagine this list could be cached when an
account is opened, or sooner.

On 3/29/2015 12:06 PM, Maxime Doyen wrote:
> Ok, here is a debug version of next release v5.0.1 wich is still on rc state for now.
> Unzip it and test your file with it (BUT DO NOT SAVE YOUR FILE WITH THIS version).
> I activated the debug of every process in that area, please track on what line the console stop and do heavy things.
>
> please alos provide you file metrics (menu tools / file statistics)
>
> ** Attachment added: "HomeBank_debug.zip"
> https://bugs.launchpad.net/homebank/+bug/1437883/+attachment/4360115/+files/HomeBank_debug.zip
>

[Maxime DOYEN (mdoyen)]

The process is to populate the payee list (dropdown+autocomplete list)
Still thinking on best way to optimize this facing a slowness due to a gtk object itself.
So far, insert 2500 payee take 1,4s while 5000 payee file take 10s. I consider also getting in touch with gtk team to have guidance on that strange no linear increase time.

[Steve Sibelman (sib-g)]

OK, bonne chance avec l'équipe de gtk.

It is unfortunate if all aspects of the gtk object must be populated
with each invocation, and if a list cannot be pointed at a pre-built
table/array. As you can tell, I know nothing of gtk.

This issue motivates me to work harder on reducing my giant payee list.
But that is a long slow process, and I have already picked most of the
low-hanging fruit.

Merci beaucoup.

On 3/31/2015 1:22 PM, Maxime Doyen wrote:
> The process is to populate the payee list (dropdown+autocomplete list)
> Still thinking on best way to optimize this facing a slowness due to a gtk object itself.
> So far, insert 2500 payee take 1,4s while 5000 payee file take 10s. I consider also getting in touch with gtk team to have guidance on that strange no linear increase time.
>

[Maxime DOYEN (mdoyen)]

I find a way to optimize this.
2000 payee 0,3s
5000 payee < 2s

[Maxime DOYEN (mdoyen)]

got lesser than that
10000 payee < 2s
5000 < 0,5s

will ship this in v5.0.1 in the new following days

[Steve Sibelman (sib-g)]

Félicitations, et merci.

On 4/1/2015 2:32 PM, Maxime Doyen wrote:
> got lesser than that
> 10000 payee < 2s
> 5000 < 0,5s
>
> will ship this in v5.0.1 in the new following days
>