# List of tree snippets

**URL:** <https://gramps.discourse.group/t/list-of-tree-snippets/6425>\
**Category:** Help\
**Tags:** third-party-addon, supertool-script\
**Created:** [November 12, 2024, 10:35am UTC](https://gramps.discourse.group/t/list-of-tree-snippets/6425 "2024-11-12T10:35:50Z")\
**Posts on this page:** 6\
**Page:** 2

<div class="post-metadata">

**Author:** ![emyoulation](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/emyoulation/32/67_2.png) [@emyoulation](https://gramps.discourse.group/u/emyoulation)\
**Post date:** [November 14, 2024, 11:33pm UTC](https://gramps.discourse.group/t/list-of-tree-snippets/6425/22 "2024-11-14T23:33:42Z")

</div>

> [@PeterPower](#):
>
> Hiskitrees are large, from 20 000 ti 150 000 people. Key demand of Subsets is capability to run in modest time. With a tree of 25 000 (from Käkisalmi parishes) runtime was speed, but with tree of 120 000 (St. Maria parish of St. Petersburg) I stopped the run after 10 minutes, nothing seemed to advance

Doing a timing on my research tree of 50,313 people, 18700 families; the subset script ran in 27 seconds and generated 599 segments.

But it was a real pain to use the results. Because SuperTool resets each time the focus changes Category, I could look at how one segment was connected in the Graphs or Relationships. Then when switching back to People, the results had been cleared gone and the script had to be re-run.

I have to find a way to make the 599 rows into a worklist. I can download a CSV of the list. But the Edit Person links are lost. So looking them up again is… tedious.

As Peter Power said:

> [@PeterPower](#):
>
> Export/import of a subtree should be supported by setting resilient IDs or tags and developing an ad-on for matching in import.

---

<div class="post-metadata">

**Author:** ![emyoulation](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/emyoulation/32/67_2.png) [@emyoulation](https://gramps.discourse.group/u/emyoulation)\
**Post date:** [November 15, 2024, 1:19am UTC](https://gramps.discourse.group/t/list-of-tree-snippets/6425/23 "2024-11-15T01:19:55Z")

</div>

> [@PeterPower](#):
>
> Export/import of a subtree should be supported by setting resilient IDs or tags and developing an ad-on for matching in import.

If there was a way to add an selectable Attribute (or calculated) column to views, then users could leverage that column to organize and manage a worklist.

That script of could easily add the Count to a “Segment” custom attribute. If the Configurable column could be equal any named Attribute (or other 2ndry object value), then suddenly we have a lot of flexibility.

---

<div class="post-metadata">

**Author:** ![kku](https://avatars.discourse-cdn.com/v4/letter/k/6bbea6/32.png) [@kku](https://gramps.discourse.group/u/kku)\
**Post date:** [November 17, 2024, 10:25am UTC](https://gramps.discourse.group/t/list-of-tree-snippets/6425/24 "2024-11-17T10:25:37Z")

</div>

I have now updated the ‘subsets’ script at [supertool-scripts/subsets at main · kkujansuu/supertool-scripts · GitHub](https://github.com/kkujansuu/supertool-scripts/tree/main/subsets).

The script can now add an attribute to each person indicating the subset it belongs to. Additionally there are options to connect people through events, citations and associations.

---

<div class="post-metadata">

**Author:** ![emyoulation](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/emyoulation/32/67_2.png) [@emyoulation](https://gramps.discourse.group/u/emyoulation)\
**Post date:** [November 17, 2024, 11:31am UTC](https://gramps.discourse.group/t/list-of-tree-snippets/6425/25 "2024-11-17T11:31:12Z")

</div>

You note in the README.md that setting the attributes can be quite slow.

Would temporarily disabling [signals](https://gramps-project.org/api_2_2_x/GrampsDb._GrampsDBCallback.GrampsDBCallback-class.html) while setting attributes speed up the processing?

> # Stopping and starting signals
> 
> Signals can be blocked on a per instance basis or they can be blocked for all instances of the GrampsDBCallback class. disable\_signals() can be used to block the signals for a single instance and disable\_all\_signals() can be used to block signals for the class:

---

<div class="post-metadata">

**Author:** ![kku](https://avatars.discourse-cdn.com/v4/letter/k/6bbea6/32.png) [@kku](https://gramps.discourse.group/u/kku)\
**Post date:** [November 17, 2024, 1:24pm UTC](https://gramps.discourse.group/t/list-of-tree-snippets/6425/26 "2024-11-17T13:24:09Z")

</div>

Thanks, good idea. However, this had only a small effect.

The real reason for the slowness was that I had my ‘Fulltext search’ addon active for this database. That catches all database writes and updates its search index accordingly - which is a bit slow. I disabled the fulltext addon and now the whole operation takes only a few seconds (for the sample database).

I think I still leave the disable\_signals call in the code.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/gramps/original/1X/2ac1e712b7adf612e31ca08a55419f4cf37c0158.png) [@system](https://gramps.discourse.group/u/system)\
**Post date:** [December 17, 2024, 1:24pm UTC](https://gramps.discourse.group/t/list-of-tree-snippets/6425/27 "2024-12-17T13:24:19Z")

</div>

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

[Previous page](https://gramps.discourse.group/t/list-of-tree-snippets/6425.md?page=1)
