Example of Very Slow RM8 Performance That Is Repeatable

I have posted before about certain RM8 scenarios where it is so slow that it acts like it is locked up. My prime culprit has been Advanced Search. In an effort to avoid Advanced Search, I have tried using groups instead. But I can get the same sort of slowness when using groups. I don’t see the problem when groups are small, but I do see the problem when groups are large.

The performance problem is not in making groups. RM8 makes groups as fast or faster than RM7. It turns out that RM8 makes groups very quickly even if the groups are large. So that’s a good thing. The performance problem where RM8 is so slow with large groups is in filtering the sidebar Index by a large group or in filtering People List view by a large group.

Here is a link to a screencast that illustrates the problem. The length of the video is 7:16. RM8 Slowdown Filtering By Large Groups

I mostly managed to avoid typo types of errors in making the video. One of my sample groups was for people who died in 1908 and for whom I didn’t have a death certificate type of record. In the video, I said that the group was for people who died in 1908 and for whom I didn’t have a birth certificate type of record. I also said that I was closing the Windows Task Manager when in fact I was closing RM8’s Edit Person screen. Other than that, I think the screencast is pretty clean.

How many people in the whole database? I would like to compare it against RM7. Can you open a support ticket and I’ll give you a link to upload a backup.

The whole RM8 database is about 49,000 individuals, down from about 60,000 a couple of years ago. It’s an import from my RM7 database.

I didn’t do a compare and contrast in my video, but the same filtering is instantaneous in RM7. It seems likely that the underlying cause of the slow filtering in RM8 is the same as the cause of the slow Advanced Searches in RM8 I had reported previously.

I’ll open a support ticket as requested.

Renee…Jerry: I tried to replicate this problem on my MBP M1 Pro using a 400 person database (largest I have). An advanced search for birth before 1980 or blank marriage seemed to finish almost instantly and I could click and edit a person whose changes got saved at once. However, RM8 does use ~40% cpu FOR ANY ACTION and then drop back down to ~15% at idle. RAM usage is moderate. There is just something drastically wrong in how RM8 executes any cpu action.

I don’t think it’s possible to replicate the problem on a database that small. RM8 will periodically burst to high CPU utilization but the burst will be over very quickly with so little data.