Re: [GNC-dev] Performance regression loading account

Maarten,
I am curious how you created that graph?
Also can you build 4.903?

I am wondering if it is down to the sorting of the list store, by default
gnc_item_list_new has sorting enabled so on every entry the list will be
sorted.
I wonder if it was disabled and in gnc_split_register_load we enabled the
sorting at the end after all entries added it would improve the situation.
I only have 719 transactions for an account in my test file so not sure I
will see the difference.
Regards,
Bob



On Mon, 13 Mar 2023 at 03:44, john <[email protected]> wrote:

>
>
> > On Mar 12, 2023, at 1:28 PM, Maarten Bosmans <[email protected]>
> wrote:
> >
> > Hi all,
> >
> > When testing the 4.902 flatpak, I noticed that loading an account
> > takes several (~4.5) seconds. This account has about 24k transactions
> > and loads in less than half a second on the GnuCash 4.8 from my
> > distribution. Is this a regression because of a code change, or
> > perhaps simply the result of a debug build in the flatpak?
> >
> > From the attached flamegraph you can see that a lot of time is spent
> > in `g_utf8_collate` for the quickfill insert. That function does not
> > appear below `gnc_quickfill_insert` for the 4.8 run. I did a quick
> > search in the git history to see that may be some caller was changed
> > to the `QUICKFILL_ALPHA` sort method, but could not easily find such a
> > thing.
> >
> > Another difference with 4.8 is stat `gnc_table_realize_gui` (which
> > takes 0.85s) does not appear below
> > `gnc_plugin_page_register_create_widget` and that function only takes
> > 0.03s in total. This time seems to be spent in Gtk.
> >
> > I don't think this is a release blocking bug, but GnuCash feels quite
> > sluggish to me, so it would be nice to fix this papercut before 5.0.
> > Any pointers on how to proceed?
>
>
> My first guess is that it's from creating a cache of quickfill entries to
> populate a drop-down list of possible entries similar to the way the
> transfer account field has worked for a couple of years.
>
> An obvious optimization is to get a collation key with g_utf8_collate_key
> for each string and use that for doing the actual sorting/ordered
> inserting. It's still a char-by-char comparison but it saves having to
> validate and normalize the strings on every compare.
>
> Regards,
> John Ralls
>
> _______________________________________________
> gnucash-devel mailing list
> [email protected]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>