Bug 268274

Summary: kmymoney 4.5.3 hangs for ~60 seconds upon right clicking payee from payees tab
Product: kmymoney Reporter: Bob Mroczka <rmroczk>
Component: generalAssignee: KMyMoney Devel Mailing List <kmymoney-devel>
Status: RESOLVED FIXED    
Severity: normal CC: 20120808_bugs.kde.org, alan.m.hughes, martin.tlustos, mguttman, n.baughman, onet.cristian, yzhernand
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Ubuntu Packages   
OS: Linux   
Latest Commit: Version Fixed In:

Description Bob Mroczka 2011-03-12 03:47:21 UTC
Version:           unspecified (using KDE 4.6.1) 
OS:                Linux

strace on process yields thousands of repeated clock_gettime(CLOCK_MONOTONIC... calls.  same behavior occurs from ledger when right clicking a transaction and then choosing go to payee.  other all activity performed within the application is very responsive and does not cause this hanging behavior.
i performed a consistency check and the OK dialog returned almost instantaneously.

Reproducible: Always
Comment 1 Cristian Oneț 2011-03-24 19:51:34 UTC
This is caused by a performance problem in the payees view caused by the complexity of KPayeesView::slotSelectPayee(void) which, depending on the dataset, can take a while (I observed 1-2 seconds on my production version of the application).
Comment 2 Cristian Oneț 2011-03-24 20:45:55 UTC
Further information to help pinpoint the source of the problem:
Timer(KPayeesView::slotSelectPayee): 24 elapsed
Timer(KPayeesView::slotSelectPayee stage 2): 481 elapsed
Timer(KPayeesView::slotSelectPayee end): 11 elapsed
Timer(KPayeesView::slotSelectPayee): 0 elapsed
Timer(KPayeesView::slotSelectPayee stage 2): 482 elapsed
Timer(KPayeesView::slotSelectPayee end): 10 elapsed
Timer(KPayeesView::slotSelectPayee): 258 elapsed
Timer(KPayeesView::slotSelectPayee stage 2): 479 elapsed
Timer(KPayeesView::slotSelectPayee end): 11 elapsed

Where "stage 2" means that I had split the KPayeesView::slotSelectPayee function in two because it's pretty complex with "stage 2" beginning from line 417. As it can be seen from this trace the performance problem is somewhere between lines 370 and 417.

Some examples would be:
    for (int i = 0; i < m_payeesList->count(); ++i)
      m_payeesList->item(i)->setFlags(Qt::ItemIsSelectable | Qt::ItemIsEnabled);

and 
  for (int i = 0; i < m_payeesList->count(); ++i)
    m_payeesList->item(i)->setFlags(Qt::ItemIsEditable | Qt::ItemIsSelectable | Qt::ItemIsEnabled);

each of these calls emmit an itemChanged signal which is connected to slotRenamePayee which indeed does nothing if m_allowEditing is false.
Comment 3 Cristian Oneț 2011-03-29 10:50:54 UTC
Quoting a user from the mailing list:
"Hi, I'm using kmymoney 4.5.3 in kde4.6.1/kubuntu 10.10

I moved last week from Quicken 2002 standard. Last time I tried before
that kmymoney would not import the QIF file as it was too old. However,
I was able to accomplish this by importing the QIF files into Skrooge,
and exporting as a kmymoney file. Import to kmymoney of 12 years of data
was flawless so that was great.

However, I have a list of payees that also goes back 12 years. Many
(probably 80%) are superfluous of course. However if I click on any one
of them the program will freeze and has to be forcibly closed. This also
happens if I click on any of the icons at the top of the payee list. I
have created a new blank kmymoney file and don't have this issue so I
suspect it's because of the sheer number of payees.

Is there any way I can edit the payee list from outside the program (I
wouldn't even mind clearing it) without causing damage to something else?"
Comment 4 Bob Mroczka 2011-04-09 20:01:33 UTC
(In reply to comment #2)
> Further information to help pinpoint the source of the problem:
> Timer(KPayeesView::slotSelectPayee): 24 elapsed
> Timer(KPayeesView::slotSelectPayee stage 2): 481 elapsed
> Timer(KPayeesView::slotSelectPayee end): 11 elapsed
> Timer(KPayeesView::slotSelectPayee): 0 elapsed
> Timer(KPayeesView::slotSelectPayee stage 2): 482 elapsed
> Timer(KPayeesView::slotSelectPayee end): 10 elapsed
> Timer(KPayeesView::slotSelectPayee): 258 elapsed
> Timer(KPayeesView::slotSelectPayee stage 2): 479 elapsed
> Timer(KPayeesView::slotSelectPayee end): 11 elapsed
> 
> Where "stage 2" means that I had split the KPayeesView::slotSelectPayee
> function in two because it's pretty complex with "stage 2" beginning from line
> 417. As it can be seen from this trace the performance problem is somewhere
> between lines 370 and 417.
> 
> Some examples would be:
>     for (int i = 0; i < m_payeesList->count(); ++i)
>       m_payeesList->item(i)->setFlags(Qt::ItemIsSelectable |
> Qt::ItemIsEnabled);
> 
> and 
>   for (int i = 0; i < m_payeesList->count(); ++i)
>     m_payeesList->item(i)->setFlags(Qt::ItemIsEditable | Qt::ItemIsSelectable |
> Qt::ItemIsEnabled);
> 
> each of these calls emmit an itemChanged signal which is connected to
> slotRenamePayee which indeed does nothing if m_allowEditing is false.

You hit the nail on the head.  In my particular case I have just over 1000 payees.  I made some changes to kpayeesview.cpp myself and can confirm the poor performing code is

for (int i = 0; i < m_payeesList->count(); ++i)
  m_payeesList->item(i)->setFlags(Qt::ItemIsEditable | Qt::ItemIsSelectable |
Qt::ItemIsEnabled);

I noticed about a 30 second delay while performing this loop.  In addition I found something else interesting.  When I am in the ledger and right click on a transaction then click go to payee this particular function is getting invoked twice and that this particular loop is getting called a second time compounding the delay.  my qt/c++ skills are very lacking so I'm unsure how to proceed in resolving this issue.
Comment 5 Alvaro Soliverez 2011-04-10 18:28:57 UTC
*** Bug 270596 has been marked as a duplicate of this bug. ***
Comment 6 Bob Mroczka 2011-04-23 14:48:56 UTC
(In reply to comment #2)
> Further information to help pinpoint the source of the problem:
> Timer(KPayeesView::slotSelectPayee): 24 elapsed
> Timer(KPayeesView::slotSelectPayee stage 2): 481 elapsed
> Timer(KPayeesView::slotSelectPayee end): 11 elapsed
> Timer(KPayeesView::slotSelectPayee): 0 elapsed
> Timer(KPayeesView::slotSelectPayee stage 2): 482 elapsed
> Timer(KPayeesView::slotSelectPayee end): 10 elapsed
> Timer(KPayeesView::slotSelectPayee): 258 elapsed
> Timer(KPayeesView::slotSelectPayee stage 2): 479 elapsed
> Timer(KPayeesView::slotSelectPayee end): 11 elapsed
> 
> Where "stage 2" means that I had split the KPayeesView::slotSelectPayee
> function in two because it's pretty complex with "stage 2" beginning from line
> 417. As it can be seen from this trace the performance problem is somewhere
> between lines 370 and 417.
> 
> Some examples would be:
>     for (int i = 0; i < m_payeesList->count(); ++i)
>       m_payeesList->item(i)->setFlags(Qt::ItemIsSelectable |
> Qt::ItemIsEnabled);
> 
> and 
>   for (int i = 0; i < m_payeesList->count(); ++i)
>     m_payeesList->item(i)->setFlags(Qt::ItemIsEditable | Qt::ItemIsSelectable |
> Qt::ItemIsEnabled);
> 
> each of these calls emmit an itemChanged signal which is connected to
> slotRenamePayee which indeed does nothing if m_allowEditing is false.

I commented out both of these for loops and recompiled. I am no longer having the issue and I am not noticing any unexpected behavior.
Comment 7 Mike 2011-04-29 13:46:10 UTC
I am seeing a 1-2 minute delay whenever I do anything on the payee list, e.g.
* right-click on a name
* left click to select another payee
* double-click to rename

I don't have the source code installed, just got the package via yum.  So it's not easy for me to change the code as suggested above.

Will a fix for this be implemented soon?  It really makes the program painful to use, considering that most other things work well.
Comment 8 Alvaro Soliverez 2011-05-02 02:09:46 UTC
I agree with the change. Those lines of code are a leftover of the KDE3 widgets. It is no longer necessary, as the edit is only allowed when only 1 item is selected anyway. And double-clicking selects 1 item too.

If no one objects, I will commit the fix suggested above, removing those lines of code.
Comment 9 Alvaro Soliverez 2011-05-03 02:20:52 UTC
SVN commit 1230245 by asoliverez:

Removed setting the flags of each PayeeItem individually. This should solve the performance problem when managing payees.
BUG:268274

 M  +0 -7      kpayeesview.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1230245
Comment 10 Brendan 2011-05-03 03:57:01 UTC
Thanks for fixing that bug. It was driving me crazy:) I just compiled and it
does not hang any more.

----
Brendan





On Mon, May 2, 2011 at 5:20 PM, Alvaro Soliverez <asoliverez@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=268274
>
>
> Alvaro Soliverez <asoliverez@kde.org> changed:
>
>           What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>              Status|ASSIGNED                    |RESOLVED
>         Resolution|                            |FIXED
>
>
>
>
> --- Comment #9 from Alvaro Soliverez <asoliverez kde org>  2011-05-03
> 02:20:52 ---
> SVN commit 1230245 by asoliverez:
>
> Removed setting the flags of each PayeeItem individually. This should solve
> the
> performance problem when managing payees.
> BUG:268274
>
>  M  +0 -7      kpayeesview.cpp
>
>
> WebSVN link: http://websvn.kde.org/?view=rev&revision=1230245
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug.
> _______________________________________________
> KMyMoney-devel mailing list
> KMyMoney-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kmymoney-devel
>
Comment 11 Yözen Hernández 2011-05-03 04:04:11 UTC
Agreed. Thank you very much.

I can't compile 4.5.3 and above because then I'd have to get the latest AqBanking libraries, but just commenting out those loops, as previously described, does the job.
Comment 12 Cristian Oneț 2011-05-06 16:22:25 UTC
*** Bug 262419 has been marked as a duplicate of this bug. ***
Comment 13 Alvaro Soliverez 2011-12-30 22:07:38 UTC
*** Bug 290209 has been marked as a duplicate of this bug. ***
Comment 14 Cristian Oneț 2012-03-07 13:17:06 UTC
*** Bug 295465 has been marked as a duplicate of this bug. ***