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

[John Ralls]

> On Jun 18, 2018, at 1:32 PM, Christian Stimming <christian at cstimming.de> wrote:
> 
> Am Sonntag, 17. Juni 2018, 20:09:24 schrieb John Ralls:
>>> 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?
>> 
>> 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.
> 
> Yes. Although what I'm concerned with is only the lookup performance, not the 
> serialization place of that option. The serialization may be kept unchanged 
> completely.

Right. So thinking about that some more, persistence (I think that’s a better description of this than serialization) is driven by the backends rather than the objects, so you can create a member variable and as long as you don’t tell the backends about it it won’t be a problem. That seems to be what you’ve tried to do in your patch.
> 
>> 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.
> 
> Yes. I've introduced some caching of this value here, but I still need a 
> little bit of help: 
> https://github.com/cstim/gnucash/commit/376cc19b7143983ce297f2272abf1a44e72fd851
> This change gets the register UI back to the old speed again. No more 1 second 
> delay after hitting enter. (I wonder why I seem to be the only one who got 
> bugged by this, but whatever.)
> 
> However, I broke the original feature in that change. To reproduce: Open some 
> register where there is some text in the "Num" field, say "1111". Switch on 
> the "Double Line" view mode. Then open File -> Properties, and on the first 
> tab, activate the option "Use Split Action Field for Number". Press Ok. Before 
> my commit, in the opened register the "1111" now moved from the first line of 
> the txn to the second line, and vice versa after changing that option again. 
> Unfortunately my commit broke that feature. Maybe someone has a good idea why? 
> Thanks for some pointers.

As a first guess I’d look at the hook list execution to make sure that your adding qof_book_option_num_field_source_changed_cb isn’t somehow preventing gnc_plugin_page_register_sort_book_option_changed (in gnucash/gnome/gnc-plugin-page-register.c) from running.

Regards,
John Ralls