Re: [Gramps-devel] People Model speedup

[Benny M. <ben...@gm...>]

2009/6/24 Gerald Britton <ger...@gm...>:
> So... I'm playing around trying to speed up how people view works.  In
> the method build_tree in PeopleView.py, I wrapped just one statement
> with commands to disconnect the tree from the model and reconnect it
> after:
>
>            self.tree.set_model(None)  # disconnect model from tree
>            self.build_columns()
>            self.tree.set_model(self.model)  # reconnect model to tree
>
> This one change seems to have restored normal performance.  To test
> this,  I first added a "print ..." to thefirst_child() method in
> _PeopleModel.py,  loaded up the small sample.ged in svn, then changed
> one name from Smith to Smithx.  Before the little patch above,
> changing the name caused about 5600 calls to first_child() (!).
> Retesting with this little patch reduced the calls to just 70 or so.
> I call that an improvement!

First, if on my box I add this print statement on the example database
(2090 people), I obtain one print of first_child (I suppose you added
it in NodeTreeMap) on load. Then, if I move my mouse over entries, it
prints one line per row. Changing a name and save causes some 5 to 10
prints depending on how much of the treeview becomes visible.

Conclusion: this speeddown you have is some kind of regression. One
would think from above too many X events or so are triggering change
as the edit dialog closes. That is, GTK is in different threads, in
one thread we are rebuilding the model, in the other thread X events
need to be processed to redraw the TreeView, causing calls to the iter
methods. Changing the columns while that happens probably does not
help either.

What you do to remove the model then reattach, is quite standard, so I
see no reason to not do that as a solution now in 31 and trunk. It
might cause a slowdown for the people who don't have this problem, who
knows?
 I believe for trunk we must work on a way that does not need the
columns to be rebuild on a simple change of names. Unattaching a model
and reattaching will probably cause all the visible treeview to be
reconstructed on screen, as opposed to only the part that is needed.
I'm no expert, I wouldn't know.

Instead of the change you know mention, I believe you can just wait
with attaching the model in build_tree. So, in the start of that
method, set the model to none, perhaps do a del on the present model
if not None, so it really goes away as soon as possible, then only
after building the columns, attach the model.

If you do that patch now, and we wait some time, it should be used
quite a bit before next release.

Benny