https://bugs.kde.org/show_bug.cgi?id=463708
Jack <ostrof...@users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #8 from Jack <ostrof...@users.sourceforge.net> --- Importing 100 rows took under 3 seconds. I only let the whole file go about 7 minutes before killing it, so it may well have gone near or over 10 minutes.. My best guess is that the time to process each row is increasing linearly with the number of payees, because it is creating a new payee for each row (the text may be the same, but the digits at the end are different) and for each row, it needs to compare against all the existing payees to see if the payee already exists. I would personally call your sample csv is a pathological example (meaning it triggers a possibly problem behavior in the worst possible way.) To be sure, I would time the import of 100, 200, 300, ... rows to see how the time compares to number of rows. My personal data file, which has data for well over 10 years, has 950 accounts (including 723 stock accounts, many closed) but only 335 payees. Note I don't keep a separate payee for absolutely every different possible one - I have some like "Miscellaneous gas station" and "Miscellaneous grocery store" with individual ones only for Payees I frequently use. So - I see how that file can take an excessively long time to import, but I think it is because the file is not really a good example of real data. If you really do expect to be importing thousands of transactions at a time, with very little possibility of recognizing payees as already known, then you will end up with slow imports, and I can't think of any way to make the program faster at what it has to do. Note it might well be notably faster if you used shorter payee examples, as your samples are all over 200 characters. -- You are receiving this mail because: You are watching all bug changes.