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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
