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 <jra...@ceridwen.us> wrote: > > > > On Mar 12, 2023, at 1:28 PM, Maarten Bosmans <mkbosm...@gmail.com> > 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 > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
