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