Navigation 2.5.1

[Robert Fewell]

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 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.

John's idea sounds interesting and may be how this ends up after the
wrinkles have been sorted.

Robert


On 21 May 2013 14:49, John Ralls <jralls at ceridwen.us> wrote:

>
> 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
>
>