Am Mittwoch, 20. Juni 2018, 17:45:42 schrieb John Ralls:
> > On Jun 20, 2018, at 2:29 PM, Christian Stimming
> 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.
> >
> >
> On Jun 20, 2018, at 2:29 PM, Christian Stimming
> wrote:
>
> Am Mittwoch, 20. Juni 2018, 09:59:52 schrieb John Ralls:
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
Am Mittwoch, 20. Juni 2018, 09:59:52 schrieb John Ralls:
> >> 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
> On Jun 18, 2018, at 1:32 PM, Christian Stimming
> 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
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?
>
>
> On Jun 17, 2018, at 1:38 PM, Christian Stimming
> wrote:
>
> Dear all,
>
> after the initial success in resolving some of the malloc/free calls due to
> vector allocation for speeding up the user interface for large files,
> I looked into some more causes of slower reaction time in the
