Navigation 2.5.1

[Derek Atkins]

Robert Fewell <14ubobit at gmail.com> 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 <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
>

-- 
       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
       warlord at MIT.EDU                        PGP key available