Re: [Gramps-devel] Scrolling page-down in people view behaves really funny

[Don A. <don...@co...>]

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=20
   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 =3D 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 =3D database.find_person_from_handle(handle)
        name =3D build_name(person)
        LRU[handle] =3D 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=20
    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,
>=20
> 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?
>=20
> Mine is P4 2000 GHz CPU, 512MB RAM, but kinda slow disk (laptop).
>=20
> > One other thing I noticed which is different in the People-view compare=
d
> > to all the other views. When I press the Page-Down, first the blue curs=
or
> > 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 th=
at
> > 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> > ALso it looks like gramps gets a new Page-Down event when it is still i=
n
> > 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.
> >=20
> > 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.
>=20
> 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.
>=20
> Alex
>=20
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share y=
our
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________ Gramps-devel mailing list=
 Gra...@li... https://lists.sourceforge.net/lists/lis=
tinfo/gramps-devel