Re: [Gramps-devel] =?iso-8859-6?q?Scrolling_page-down_in_people=09vie?= =?iso-8859-6?q?w=09behaves=09really_funny?=

[Kees B. <kee...@xs...>]

Don and Alex,

Thank you for the answers so far. Personally I think the speed of the PC
is not so much a parameter for this problem. But I was surprised to hear
that Don doesn't see it on his computer. The specs of his computer aren't
that much better than mine. OK, Alex beats us all with his 2000GHz, but he
has the problem as well. And I see it also on a second computer, a laptop
with a 1.6GHz Centrino Duo with 1Gb memory.

Thanks for describing some details. I'll try to dig in myself too.

Do you think it is related to the long time it takes when I press those little
triangles? I know the number of "Bakker"-people is quite big in my database,
it takes roughly 4-5 seconds after the "Bakker"-node expands. If I want to
give gramps to my 84-year father (which was the whole purpose of me joining
the gramps work) then he will be confused whether he pressed that triangle
or not. And collapsing takes that amount of time too.

- Kees

Op dinsdag 28 november 2006 22:55, schreef Don Allingham:
> Most of what is happening is a result of GTK. The only thing we can
> really affect is the display of the cells. GTK makes a request of us to
> return the cell's contents. All we do is return the cell contents based
> of the position we are given.
> 
> In fact, until you mentioned it, I was not aware that PgDn worked :-)
> 
> The basic algorithm we have to provide the cell contents is:
> 
> 1) GTK gives us a Node value (row indicator) and a column. We have set 
>    things up so that the Node value we are given is our database handle.
> 2) Based on this, we use the column to select the function we call, and
>    pass the database handle to this routine.
> 3) The routine calculates the return value based off the handle.
> 
> We don't have the space to hold all the text strings in memory, so we
> have generate them when they are requested. Normally, this isn't too
> bad. Some functions, in particular are expensive. The Person's name is
> one of these.
> 
> To aid in reducing the time, We have a LRU cache (least recently used)
> which stores the last 500 names that were calculated. So while the old
> algorithm was:
> 
>   def display_name_column( handle ):
>      person = database.find_person_from_handle(handle)
>      return build_name(person)
> 
> The new algorithm is:
> 
>   def display_name_column( handle ):
>      if LRU.contains(handle):
>         return LRU[handle]
>      else:
>         person = database.find_person_from_handle(handle)
>         name = build_name(person)
>         LRU[handle] = name
>         return name
> 
> So, if the person has been recently used, no database look up or name
> calculation is required.
> 
> This is important, because this function gets called all the time - not
> just for display, but for sorting, searching, and everything else. For a
> sort, this can eliminate 1000s of database accesses.
> 
> Based off of this, I can only think of two things which could be causing
> the problem.
> 
>  1) PgDn causes us to miss everything in the cache, and we have to build
>     everything. In this case, our performance should be quite close to
>     2.2.1 or before levels, since we will only pay the cost of a few
>     memory lookups and a few memory assignments. I doubt this is the
>     case, because this can also happen on a basic scroll.
> 
>  2) GTK is doing something strange on a PgUp or PgDn - probably not
>     something related to cell contents, but maybe something odd with 
>     screen positioning.
> 
> If this is a significant problem, we can add some tracing calls to try
> to figure out what GTK is doing on a PgUp/PgDn. We had to do this for
> sorting and searching, since they used to be major performance
> bottlenecks (and led to our LRU scheme).
> 
> Don
> 
> On Tue, 2006-11-28 at 13:24 -0800, Alex Roitman wrote:
> > Kees,
> > 
> > On Tue, 2006-11-28 at 22:08 +0100, Kees Bakker wrote:
> > > I didn't think my PC is too slow. It's an Athlon 3200+, and I have
> > > 1Gb memory. Not a low end PC, I should think. Don, what are the
> > > specs of your PC? And Alex, how about yours?
> > 
> > Mine is P4 2000 GHz CPU, 512MB RAM, but kinda slow disk (laptop).
> > 
> > > One other thing I noticed which is different in the People-view compared
> > > to all the other views. When I press the Page-Down, first the blue cursor
> > > line highlights the third line from the bottom, then the whole view
> > > is updated to bring that highlighted line on top. This goes pretty slow
> > > compared to scrolling in all the other views. It could be that the
> > > People-view has many more entries in total, but in number of entries that
> > > are visible. When I say "slow" I mean that it is very noticible what
> > > steps it takes. It's not a snap, snap, jumping to the next view of
> > > entries.
> > 
> > The people view is different from other views in a few regards.
> > First is that it is grouped by the surname -- other views are flat.
> > 
> > Second is that computing the name is very expensive, because
> > it goes through the NameDisplay routine to account for the name
> > preferences set. This is done for every person displayed.
> > In contrast, other views usually display the naked fields of
> > the primary records, with little computation needed.
> > Also depending on the column settings, the people view
> > may display things like the spouse name etc that need yet more
> > computation.
> > 
> > Third is that, because of a huge overhead need for displaying
> > the person, starting in 2.2.2 we used the cache. We cache 500
> > last used entries, so that the small movements can avoid hitting
> > the database. This way you can scroll a page up or down without
> > any slowness. I am not sure whether this cacheing is the culprit.
> > I suppose it could be, if every time now we need to read 500
> > entries instead of less than 50 that we would need to in order
> > to draw the screen, but I am not positive. Don is the person
> > to enlighten us on this one.
> > 
> > > ALso it looks like gramps gets a new Page-Down event when it is still in
> > > the middle of updating a previous Page-Down event. And then the cursor
> > > is not positioned in view anymore. If that has happened, gramps is
> > > totally confused about the position and how to update the view.
> > > 
> > > I wonder if there is anything I can examine myself. But I have no clear
> > > understanding how a Page-Down is handled and what it all does in Gramps.
> > > Or how much GTK/Gnome is handling. If you could give me a hint where to
> > > look, I could try to investigate it myself.
> > 
> > It could be inside gtk. Gnome has nothing to do here, the tree
> > view is implemented in gtk. As to how to profile it: I have no clue :-)
> > Don has been battling the performance of the gtk tree view
> > for a long time, maybe he knows more.
> > 
> > Alex
> > 
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys - and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________ Gramps-devel mailing list Gra...@li... https://lists.sourceforge.net/lists/listinfo/gramps-devel
>