Version: 4.5.2 (using KDE 4.5.5) OS: Linux KMyMoney has become very slow when editing (or cancelling the edit) of a Ledger entry. Reproducible: Always Steps to Reproduce: Easily reproduced but do not know what triggered the degradation. System monitor shows high CPU utilisation. However this is a new machine 4 core AMD phenom2 965 with 8GB. Noticed some posts relating to video so thought View | Show Transaction Detail might be relevant. Ran with debug timers and found significant difference - factor of 10X. See below Actual Results: Edit and then Cancel Ledger entry with Show transaction detail on: Timer(Start adjusting column 0): 53441 elapsed Timer(Start adjusting column 6): 89 elapsed Timer(Start adjusting column 7): 126 elapsed Timer(Start adjusting column 11): 78 elapsed Timer(Start adjusting column 0): 186 elapsed Timer(Start adjusting column 6): 88 elapsed Timer(Start adjusting column 7): 127 elapsed Timer(Start adjusting column 11): 78 elapsed Timer(Update register): 40873 elapsed Timer(Done updateing register): 0 elapsed Timer(Update register): 3531 elapsed Timer(Done updateing register): 5122 elapsed Timer(Update register): 293 elapsed Timer(Done updateing register): 0 elapsed Timer(Update register): 2460 elapsed Timer(Done updateing register): 5088 elapsed Now with Show transaction detail OFF: Timer(Update register): 35329 elapsed Timer(Done updateing register): 1 elapsed Timer(Update register): 178 elapsed Timer(Done updateing register): 2385 elapsed Timer(Update register): 10 elapsed Timer(Done updateing register): 584 elapsed Timer(Start adjusting column 0): 23 elapsed Timer(Start adjusting column 6): 55 elapsed Timer(Start adjusting column 7): 81 elapsed Timer(Start adjusting column 11): 50 elapsed Timer(Update register): 123 elapsed Timer(Done updateing register): 0 elapsed Timer(Update register): 156 elapsed Timer(Done updateing register): 0 elapsed Timer(Update register): 4871 elapsed Timer(Done updateing register): 628 elapsed Timer(Update register): 142 elapsed Timer(Done updateing register): 0 elapsed Timer(Update register): 2216 elapsed Timer(Done updateing register): 600 elapsed OS: Linux (x86_64) release 2.6.35-28-generic Compiler: cc Ubuntu 10.10
Could you try to run the SVN version to see if the issues are still there (we made some performance improvements since 4.5.2) or attach an anonymous version of your file so we can check if the performance problem is still present in SVN trunk? Thanks!
Does this still happen with the latest release?
Created attachment 92374 [details] Anonymous db file Anonymous file to reproduce problem
I am seeing this on Debian using 4.6.6. I have attached the anonymous db file which I checked shows the problem. It takes 4s to update an entry with show details off and 10s to update with show details on. You get 100% CPU usage in both cases. This only happens on ledgers with lots of transactions so make sure you choose one of those ledges, eg in the above file A000001.
Same behavior here on 4.6.6. openSUSE 13.2 using Phenom II 1090T 3.6Ghz/16GB RAM. On a ledger with ~12000 transactions hitting enter takes 100% cpu. Using a stopwatch I consistently get ~8 seconds to complete the entry transaction with details off, ~16 seconds with details on. I've used KMyMoney since 2007 and really like it, but this condition is nearing intolerable. Performance test result: --- Starting performance tests --- accountList() First time: 0 msec Total time: 313 msec Average : 0 msec balance(Asset) First time: 0 msec Average : 0 msec totalBalance(Asset) First time: 0 msec Average : 0 msec balance(Expense) First time: 0 msec Average : 0 msec totalBalance(Expense) First time: 1 msec Total time: 505 msec Average : 0 msec transactionList() First time: 15 msec Total time: 1462 msec Average : 14 msec transactionList(list) First time: 15 msec Total time: 1455 msec Average : 14 msec
I can't really see any prospect of attempting to fix a problem on such an old release. Please, can't you upgrade to a current version? 4.7.2 includes numerous bug fixes, and 4.8.0 was released quite recently. If the problem is still present, then there is a far better prospect of finding a fix.
Thank you Allan for the very quick reply. As it turns out, 4.8.0-13.3 was just added this morning to the openSUSE 13.2 KDE:Extra unsupported repository. I installed it and good news the cpu spike and delay in posting ledger transactions has apparently been fixed. Thanks! However, I noted in the Change Log for 4.8.0 the following: * Categories no longer have opening date, which caused annoyingerrors both during input and while running the consistency check * Fixed some annoying consistency check errors When I ran 4.8.0 the first time, and each time the file is saved, the Consistency Check is run and it is returning over uncorrectable 5000 errors, each indicating a posting date that is older than the opening date of the account. All of the transaction data in the log is for 2007 and older; I can't say if there are such errors in newer data. It may be that most of the errors are in data that was imported, but for a certainty I began using the application after the import in about 2005 so there are errors in at least some newer data.
(In reply to Dennis Gallion from comment #7) > Thank you Allan for the very quick reply. As it turns out, 4.8.0-13.3 was > just added this morning to the openSUSE 13.2 KDE:Extra unsupported > repository. I installed it and good news the cpu spike and delay in posting > ledger transactions has apparently been fixed. Thanks! > > However, I noted in the Change Log for 4.8.0 the following: > > * Categories no longer have opening date, which caused annoyingerrors both > during input and while running the consistency check > * Fixed some annoying consistency check errors > > When I ran 4.8.0 the first time, and each time the file is saved, the > Consistency Check is run and it is returning over uncorrectable 5000 errors, > each indicating a posting date that is older than the opening date of the > account. All of the transaction data in the log is for 2007 and older; I > can't say if there are such errors in newer data. It may be that most of > the errors are in data that was imported, but for a certainty I began using > the application after the import in about 2005 so there are errors in at > least some newer data. The fix was specific to categories having an opening date. You may still have other accounts with problem dates, I'm afraid.
Denis: it seems odd to me, that KMyMoney cannot resolve such a high volume of problems automatically. There are circumstances it does not touch the data without human interaction, but I don't expect them in the thousands. To analyze this furhter, can you provide us with an anonymized version of your file? Instructions can be found on https://docs.kde.org/stable4/en/extragear-office/kmymoney/details.formats.anonymous.html. If you prefer you can send the file to me via private email. Thanks in advance.
Thank you Thomas for your help. I think I found the source of the problem and have resolved it: At first run the consistency log showed 185 errors corrected; 5458 could not be corrected. The problem was apparently created when I first set up KMyMoney on 6/10/2007 and performed a conversion import from IIRC the Windows application I had been using (I don't recall whether I used qif or csv). The accounts all had an opening date of 6/10/2007, whereas there were transactions in some accounts dating back to 1/2/1998. Using the largest account, I edited its opening date to 12/31/1997. The consistency log then showed the number of uncorrected errors reduced to 1841; all errors for that account were resolved. I used this process for the additional accounts, one at a time, editing the opening date to be a couple days before the earliest transaction for that account. Following each account opening date change, I re-ran the consistency report. The number of errors reduced from 1841 to 346, then to 33, then to 0. So in summary apparently the errors are caused by transaction dates being earlier than the account opening date. Since 185 errors were corrected, I suspect that the program auto corrects such errors when they are only within a specific time window. Btw, when I attempted to change the account opening date by manual entry, the screen would not permit it. I needed to use the associated calendar and scroll back to the older date; the change was then accepted. The solution of course is for the user at setup, if doing an import conversion, to ensure that the account opening date is older than the oldest imported date, rather than the setup date. I have sent to your email address the anonymous file you requested, and a copy of each consistency log file as I went through the process described above. Thanks again for your and Alan's assistance. I really like KMyMoney!
Thomas, I received your email re the anonymized file not being included in my email to your private address. I sent another email via the web browser version of gmail (kmail errors on an attachment >4.9MB; grrr) with that 8.5MB file attached, but that email is bouncing back from kde.org as "delayed" with this message: Technical details of temporary failure: Missed upload deadline (899.94s) (state SENT_MESSAGE) I attempted to attach the file here, but the bug system limits attachments to 4MB. Using Dropbox, while the Copy Public Link does not work on the client side, it appears to work logged on via browser. So here is the Dropbox public file link. Let me know if this doesn't work and we'll try something else (hope you have a suggestion). https://www.dropbox.com/s/q27xk24y3lnwc2w/anonymous_1.anon.xml?dl=0
Got the file: 8.5 MB. Using gzip on it leaves around 0.5 MB which is approx. 6% of the original size :) (compression does the trick)
*** Bug 322620 has been marked as a duplicate of this bug. ***
Marking as fixed as per comment #7.