Navigation 2.5.1

John Ralls jralls at ceridwen.us
Tue May 21 09:49:57 EDT 2013


On May 21, 2013, at 1:54 AM, Geert Janssens <janssens-geert at telenet.be> 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




More information about the gnucash-devel mailing list