Thanks to a post elsewhere by @thejerrybryan, I have just discovered the joys of groups based on criteria. As I understand these, RM uses criteria to mark the people in the group, but for performance reasons sensibly only updates the group when you press the ‘refresh people’ button on the edit group screen.
This should mean that criterion groups behave just like other groups at all times, except when you are refreshing their contents. They do not, which suggests to me that some unwanted code is doing something in the background.
I have a group of people with two or more spouses which I am using to help find marriages messed up by Ancestry. After downloading from Ancestry, RM shows one person with two almost identical marriages, one with the real spouse and one with an unknown spouse. Part of the cleanup is to unlink the unknown spouses in RM.
My observation is
-
if I move between spouses or unlink the spouse while the index frame shows the two or more spouses group, then RM hangs for c30 seconds during which time it uses lots of CPU, but
-
if I do the same thing while the index shows everyone or a freeform group, then the unlinking is almost instantaneous and I hardly notice any CPU.
This is very repeatable. I don’t plan to do it very often, so a 30 second delay in a rare event is not a big deal, but I guess that a bit of code must be doing something that it shouldn’t be.
Investigating a little further, I see that
-
a criterion group filter takes quite a bit longer to load than a filter using a freeform group with the same number of members.
-
navigating around the index is near instantaneous, whether unfiltered, filtered on a freform group or filtered on a criterion group
-
further filtering the index by typing part of a name is also near instantaneous whatever filter is applied, but
-
the response to deleting that text is much slower with a criterion filter - presumably RM reapplies the original filter when the text is deleted.
Since my original criterion filter relates to the number of spouses and I was unlinking a spouse, I wondered whether the delay and spike in CPU use happened because the edit related to the criterion. To test this, I created another criterion group with rather more members (place of birth contains ‘Ireland’) and found a spouse that I wanted to unlink from within this group. This also took c30 sec and used lots of CPU. So it seems that some operations are triggering something which uses CPU when a criterion group is used as a filter, whether or not the edit relates to the criteria.
I have posted elsewhere about ‘argument out of range’ errors that I have been getting recently and wondered whether these might be related to heavy use of this criterion group. However, on checking, I see that my first ‘argument out of range’ error predated the creation of the group concerned.
Alan
1 Like
It would take me a while to see if I can replicate your symptoms. and remember that the criteria groups are a brand new feature.
With that in mind, I have previously (and prior to the release of criteria groups) reported some very serious performance problems both with groups and with Advanced Search. For example, an Advanced Search in my database of about 47,000 people can take about 90 seconds if the search criterion is Birth => Date => Is Blank. I have watched RM with Windows Task Manager during this process. It takes 2 or 3 seconds for the percentage indicator to suggest it has finished searching my database. Then there is a very long period when RM is extremely I/O bound, presumably reading through the database one or more times. Then there is a very long time when RM is extremely CPU bound, presumably building the results list in memory but who knows exactly what.
When I made a group instead with the same criteria, the making of the group only took two or three seconds. But any time I used the group filter, there would be huge delays that I think were CPU bound. These delays could come from filtering the by the group in the Index tab in the left side bar or from filtering by the group in People List View. And remember that this was back when the only groups were the free groups. And the delays were not just when I first applied the filter. For example, I could simply go into and out of the Edit Person screen for a person in the screen and the huge delay would occur after exiting the Edit Person screen. I assume that the logic was that I might have added or removed someone from the group while I was in Edit Person, which was possible. Even if that was the reason, the Edit Person screen should have set a flag saying whether or not the person being edited had been added or removed from a group.
My workaround is that I don’t use Advanced Search at all anymore. Aside from the tremendous performance problem, it operates by making sort of a temporary and unnamed “group” and I would much prefer the behavior of Advanced Search in RM7 where it would take me to the first or next person meeting the criteria almost immediately without making the list. I don’t need the list. I just need to get to the first or next person meeting the criteria as quickly as possible.
Instead, I now make groups and I make sure that my groups are small. For example,I will filter by my desired criteria plus a criteria that effectively adds the first letter of the last name as a criterion. With small groups (a few dozen people or even a few hundred), performance of group filtering seems acceptable.
I now see that I will have to test the performance of groups again with the distinction between criterion groups and free groups. In my casual use of the new criterion groups, I don’t see the difference in performance that you are seeing, but remember that my groups are now very small.
I should have added details. I am using RM v 9.0.5.0 64 bit on Windows 11, running on a fast modern laptop with multiple cores etc. My database has 56,000 people in it. My two or more spouses group (criterion group) has 2,800 people in it, my born in Ireland group (criterion group) has 11,600 people in it and my ancestors group (freeform group) has 4,600 people in it.