Espen and others with large family trees,
I changed the way how Gramps handles signals on not active views.
Please see how that impacts how you can work with Gramps on a large
With the work Nick and I did on the listviews,
adding/deleting/updating a person on a listview is a fraction of
seconds. Hence, it is worthwhile to remove the hack introduced several
years ago to not sync listviews with the database if the view is not
active. This gave us a big performance boost at the disadvantage of
the need for a rebuild when you switched to the view again. This hack
is now removed.
In practice, once a view is build by looking at it, the view remains
in sync with the database. So you look at events, people, ..., and
then start adding people in pedigreeview or rel view. Switching back
to eventview or peopleview should be near instantanious.
The price to pay is that on save on an editor, all views are synced,
but as said, the hope is that for the reworked views that is not a
problem as it is in 3.1. Adding a single person however leads to a lot
of signals (family signals, event signals, people signals, ...)
Technically, this is governed with a single switch on the listview
class, so one can add a listview that does not sync with the database
by changing the switch in the init of the class.
My hope is this means people with a large database wait a number of
seconds to have the view load, but once that happens, starting the use
gramps is a very fast action.
2010/1/10 Benny Malengier <benny.malengier@...>:
> Espen and others with large family trees,
I would be happy to help test performance on large databases. But last
time I checked some of the files were missing from the wiki and Gramps
ran out of database handles anyway before it could load a large
database. I filed the bug is somewhere in the database. I'll find it
(only...) if someone is interested...
2010/1/11 Duncan Lithgow <duncan.lithgow@...>:
> 2010/1/10 Benny Malengier <benny.malengier@...>:
>> Espen and others with large family trees,
> I would be happy to help test performance on large databases. But last
> time I checked some of the files were missing from the wiki and Gramps
> ran out of database handles anyway before it could load a large
> database. I filed the bug is somewhere in the database. I'll find it
> (only...) if someone is interested...
To load a large .gramps file, a discribed hack on the locks of the
database must be done.
2010/1/11 Benny Malengier <benny.malengier@...>:
> To load a large .gramps file, a discribed hack on the locks of the
> database must be done.
You did. Thanks for that. But I consider that a workaround, as you say
it's a hack, not a fix. That's why I haven't followed that route. I
Gramps is supposed to work with large databases then it also needs to
deal with running out of handles gracefully. For example what about a
simple box popping up:
'You are attempting to open a database too large for Gramps in it's
current configuration. The current number of available connections is
xxxx which is not enough for your database. Please use this menu to
select a higher number"
Or whatever you all think it should say, then I will happily start
testing large databases again.