Robert Fewell <[email protected]> writes: > Theres a lot of talk about the performance of the new register which I know is > slower and I am sure it can be improved but no one has stated any real > findings. As I have said before, I am using an under resourced Gentoo Linux VM > for development and have an account with 4000 entries covering 10 years, not > sure if thats a lot or not. If I do not specify the number of entries to load, > and add an entry for last year, it takes about 8 seconds to update. If I set a > limit of 1000, then it becomes about 1.0 - 1.5 seconds. An easy way to find > the number of entries for an account is to start gnucash with --debug, open > the account and then in the trace file search for > gnc_tree_model_split_reg_load.
I think even 1-1.5 seconds for an entry is "too much". And 8 seconds is WAY too much. This still sounds like it could be a gui refresh issue. > I will have a look at the gui refresh stuff but I think some of the delay may > be with using a single cell data function as oppose to one for each column. I would try the gui refresh first to see if that helps. If that doesn't then we can profile the code to see where it's spending its time and optimize correctly. > John's idea sounds interesting and may be how this ends up after the wrinkles > have been sorted. > > Robert -derek > On 21 May 2013 14:49, John Ralls <[email protected]> wrote: > > On May 21, 2013, at 1:54 AM, Geert Janssens <[email protected]> > wrote: > > > On Monday 20 May 2013 11:28:36 Derek Atkins wrote: > >>> I've also noticed that the new register is much slower than the old > >>> one entering and deleting transactions. It takes about 8 seconds > >>> between accepting a transaction and when the the transaction is > >>> actually entered and GnuCash is ready for something else. I'm not > >>> sure what the problem is, but it's annoying. > >> > >> Could this just be a failure to disable the gui-refresh while > >> committing the changes? > >> > > That crossed my mind as well. > > > > Robert: this may be something to check when you're ready again: did you > insert > > gnc_suspend_gui_refresh and gnc_resume_gui_refresh calls at the right > locations when > > switching cells ? > > > > Without these calls there probably would be a whole explosion of gui > refresh events while the > > model is being updated internally. > > > > On the other hand it may also be that the GtkTreeView is slower than our > highly optimized old > > register code. I remember a comment from Robert somewhere that he got > good performance > > when limiting the number of entries in the register to 1000. I don't > know how well > > GtkTreeView scales to large datasets. > > How hard would it be to limit the number of rows to 3 pages, and to load > more on a scroll event? We'll > want that behavior down the road for real database operation so that we're > not read-locking every split > in the active account. > > Regards, > John Ralls > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH [email protected] PGP key available _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
