[GNC-dev] Next shot at "Slow user interface in 3.x gnucash (for large files)"

[John Ralls]

> On Jun 17, 2018, at 1:38 PM, Christian Stimming <christian at cstimming.de> wrote:
> 
> Dear all,
> 
> after the initial success in resolving some of the malloc/free calls due to 
> vector<string> allocation for speeding up the user interface for large files, 
> I looked into some more causes of slower reaction time in the user interface.
> 
> The function xaccSplitOrder is one that is called quite often. This may or not 
> may not be ok, but there's a huge performance hit of that function:
> 
> 80% of its runtime instructions are needed for the following line 
> (Split.c:1479 in maint):
> 
>  action_for_num = qof_book_use_split_action_for_num_field
>        (xaccSplitGetBook (sa));
> 
> I.e. the function qof_book_use_split_action_for_num_field is very very 
> expensive. Currently it does a KVP lookup on each call. What keeps us from 
> turning this KVP value into a normal gboolean value in the struct _QofBook? 
> What steps are needed to turn a KVP value into a normal data member? (We don't 
> happen to have a short todo list for that case, do we :) Does anyone happen to 
> know the necessary steps from memory? This would help a lot here. Thank you 
> very much.

Christian,

It’s all about file compatibility, remember? As it stands, if you make something a regular member variable then you have to change the schema to add the element/column, and write a scrub to update older data. We strongly prefer not to do that during a stable release cycle and generally require that the last version of the previous stable series be able to read both formats.

One alternative would be to redo the backends so that member variables can be designated as stored in KVP, effectively moving KVP out of engine. That would be a bit of work but it’s an alternative to changing the schemas. It’s a route we’ve discussed before but nobody’s been inclined yet to take it on.

The less involved approaches would be to cache the value or to make KVP retrieval more efficient. I suspect in this case that caching will be the easiest.

Regards,
John Ralls