What are the slowest Features in Gamps

Help
21

I think we could target some common collections, such as what @ennoborg suggested, get_all_relatives(). A few would immediately be useful: get_all_ancestors(), get_all_descendants(), etc.

Will require a two step process:

  1. move such functions to the database layer (base class)
  2. create specific ones in the subclasses

I think it is doable.

2 Likes
22

Sure, I’d like to see the test script.

But how would such scripts be applied? And then how would the subset of objects be used for a filter in a view, export, or report

23

I selected all 129K+ individuals returned by the filter (Ctrl+A) and set the tag for all of them.

24

I enjoy following these discussions and gain some really useful insights
into the workings of GRAMPS
More so since I took the decision to stick v5.1.6 given there was
nothing I could see in 5.2 worth my time on the upgrade process at which
point I thought about what would entice me to think again.

  1. Elimination of Data Blobs
  2. GRAMPS capable of running successfully from a NAS (not multi user)
  3. A hierarchical structure for Repository/Source/Citation and
    each source having a reference to the publisher(s) used.
  4. GRAMPS not running due to upgrade of operating system.

So now I can relax and enjoy the discussions more as intellectual concepts.
phil

2 Likes
25

I think your questions will be answered when you see the tests. I’ll DM it to you just to keep the traffic down in this thread.

1 Like
26

We no longer support BSDDB.

27

That was meant to be an example :smile: Replace with another current or future supported backend.

3 Likes
28

Well, this is interesting: I ran the AncestorsOf() rule/filter on all 2157 people in the Example tree.

  1. Without any changes, it clocks in at 2 minutes and 10 seconds.
  2. With some tweaks, it clocks in at 2 seconds. For all of them.

I did all kinds of low-level things (SQL, unpickle, JSON_EXTRACT(), ast.literal_eval), but the biggest difference was a high-level code change. After the ancestor-collection part of the code was completed, it takes another 2 minutes doing things it doesn’t need to do.

I think we can get great gains without having to change much except how filters are applied.

7 Likes
29

Yes, all of the tree walking rules build a list of people in the prepare method. The apply method then unnecessarily loops through the database matching the objects to the existing list.

The poor performance finding duplicate people is also a high-level issue which could be improved by retrieving people from the database in surname groups.

I’m sure that there are other places where a better choice of algorithm would help with performance.

30

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.