[GNC-dev] Bug 797463 - CSV Import of transactions into a new file hangs

John Ralls jralls at ceridwen.us
Fri Nov 8 17:08:09 EST 2019



> On Nov 8, 2019, at 1:58 PM, Christian Gruber <christian.gruber at posteo.de> wrote:
> 
> Am 08.11.19 um 04:39 schrieb John Ralls:
>> Christian,
>> 
>> It's not that it's not prepared for Bayesian matching, it's that older versions of GnuCash stored the Bayesian match tokens hierarchically. Aaron Laws (lmat) changed it to a flatter structure with somewhat better memory locality for faster access. imap_convert_bayes_to_flat should run once to convert the data and set the feature, after which check_import_map_data will see the flag and return. A file created with 3.x and Baysian maps would already have the feature set.
>> 
>> 
>> With that background, to your questions:
>> 
>> Why does it take so long? Because it traverses the entire tree of accounts, every time. The test book has 1127 accounts. Add to that that there are some things inside the loop that shouldn't be and that convert_imap_account_bayes_to_flat doesn't use some obvious short circuits and you get taking a long time.
>> 
>> Why does it run twice? Because there aren't any accounts with import-map-bayes slots, so it does no conversions so it doesn't set the feature.
> 
> Why isn't the feature set in any case after conversion is done, whether there was any slot to convert or not?
> 
> I would expect that, if the hierarchical structure should not be used anymore. I wouldn't only set the feature, if there has been any error during conversion. But it's not an error, if convert_imap_account_bayes_to_flat() returns false.

The feature isn't set because that would prevent using the file with an older version of GnuCash for no good reason: There aren't any import-map-bayes tags in the new format so there's nothing for the older version to mess up.

Regards,
John Ralls



More information about the gnucash-devel mailing list