I am experiencing speed issues with RM9. My main 2 databases, (A) contains 12606 individuals and (B) a work file contains 2952 individuals. Database (A) takes 45 seconds to open and (B) is taking 39 seconds. Also closing problem alert dialogs, without taking any action, takes 1min 55 seconds for database (A) and 45 seconds for database (B) before RM9 becomes responsive again. As a consequence I have to ignore all problem alerts as it makes the RM9 almost unusable due to the slowness. I an run RM9.0.3.0 with Windows 11 Pro (22H2) on an Intel(R) i9-7900X CPU @ 3.30GHz processor, 32GB Ram and SSD. I am sure it is not the PC.
Anyone experiencing similar issues?
Laptop - Windows 11 Home (64-bit) 22H2 (10.0.22621) IntelŽ Core⢠i7-9750H CPU, RM9 9.0.3.0 Database contains 11720 individuals. RootsMagic fully loads in under 10 seconds. No issue with problem alerts etc. I take it you have tried re-installing RootsMagic.
I agree that RM9âs performance can be sluggish. But mine opens in under 5 seconds with 47,000 individuals in the database and with a lesser machines than yours. For example, I have 16GB memory to your 32GB memory. Iâm still on Windows 10 to your Window 11, and I have a 2.60 GHz processor to your 3.30GHz processor. We both have an SSD. So your RM9 performance numbers are very puzzling. As I was reading your note, I was immediately suspicious of your disk speed until I hit the part of the note where you said you have an SSD.
Have you watched the performance of RM using Windows Task Manager during the startup to see which resources it is most consuming. For example, one of my biggest performance complaints has to do with the way Advanced Search works and with the way filtering of People List View by Groups works and with the way filtering of the sidebar Index by Groups works. I suspect the problem is basically the same between Advanced Search and Group filtering.
A relatively simple Advanced Search can take up to 90 seconds. When I have watched the search with Windows Task Manager, I see the following. It takes only a a second or two for the search to go through my whole database for the first time. Thatâs too short to see much in Task Manager. Then it spends about 30 seconds running my SSD disk at 100% capacity, probably reading my whole database again. Then it spends about 60 seconds running one of my processor cores at 100%, apparently building the results list. Since all thatâs really needed is a list of RIN numbers, I think it should be done with the whole Advanced Search after a second or two. But instead of just getting a list of RIN numbers, it appears to be building a results list that looks just like the column layout of People List View. It really shouldnât take that long, and there is no real reason to make the results list look like People List View in the first place.
Creating a Group with the same search criteria as the Simple Search is much, much faster - taking only a second or two. But when the Group is then applied as a filter, it can take up to 60 seconds. It appears not to be spending the 30 seconds reading the whole database, but it does appear to be spending the the 60 seconds building a list of some sort. But all that is needed for the filtering is a list of RIN numbers and thatâs exactly all that a Group actually is.
Those are the sorts of things I would be looking for on your computer with Task Manager - mostly disk utilization and CPU utilization. I have a 4 core processor, so a single core running at 100% shows up as the whole system running at 25% CPU utilizationâŚ
Been down that road⌠Also cleared the registry of any traces of RM9 and all traces of RM8. Has no effect. Doesnât matter where either the application or the database file is located on my PC.
Everything runs fine except for opening a database file and recovering from closing the problem alert dialog. No problems with sorts, searches, creating groups, etc.
Each of the databases have around 2000 media links. I was wondering if RM is trying to validate the links on opening.
I also have about 2000 media files. Since my startup time is so much faster, I doubt the problem lies in the validation of the media links.
My huge problem with searches and creating groups inn RM9 is clearly related to the number of hits on a search and the number of people in groups. For very small numbers of hits on a search or numbers of people in a group, I can see the slowdown but it is very slight. But if the number of hits is tens of thousands, then I see a huge performance problem. My workaround at the present time is to use search criteria that produces a very small number of hits - like no more than a few hundred.
RM7 doesnât have the same performance problem on my data. Iâm sure my problem is because of RM9 building the very large results list. For searches, RM7 doesnât build a results list at all. To me, thatâs a good thing because all I want to see is the first hit or next hit. I donât want to use a results list at all. I donât even want to use a results list for a search even if the search is fast. If I want a results list, I just make a group instead.
For groups, RM7 does have to build a results list but it is only a list of RINâs. RM9 is apparently building a fully formatted People View type of list when it is filtering by groups rather than just using the list of RINâs that already exists as a part of the group definition. Thatâs the only thing I can think of thatâs possibly taking so long in RM9 to do the group filtering.
None of this gets to the main question in this thread: why is RM9 taking so long to open for some users and not for other users? What is RM9 doing during startup that is so different between users who apparently have similar hardware configurations and similar sized databases? I donât know.
This is not directly relevant to your issue but on mac RM9 is still an Intel code only program that has to go through Rosetta translation. It also is a huge cpu hog consistently running at 20% idle while FTM 2019 and other programs use 0.1% in use.
M1 Pro 8 core cpu 14 core gpu 16GB ram 512 SSD macbook pro 14.
Just a wild thought. For users with ample CPU resources who are experiencing slow startups, does your RM9 open up in People List View that is filtered by a group or does it open up with the Index in the sidebar filtered by a group? I suspect the answer is no. But if the answer is yes, that could be the problem - or at least part of the problem.
Not a factor on my macâno filters or groups; root person pedigree view. Just slow startup due to intel only code AND non standard port to mac OS.
For reference-
RM v9.0.3 launch = 5.8 sec
File open = 1.9 sec
File referenced above-
people 10501
media items 5636
file size 109 MB (114,319,360 bytes)
Computer info (from SystemInformation.exe)
|OS Name|Microsoft Windows 11 Pro|
|Version|10.0.22621 Build 22621|
|System Manufacturer|Dell Inc.|
|System Model|OptiPlex 7060|
|System Type|x64-based PC|
|Processor|Intel(R) Core⢠i7-8700 CPU @ 3.20GHz, 3192 Mhz, 6 Core(s), 12 Logical Processor(s)|
This is a 4 year old low end desktop.
Only anti virus software installed is MS Defender, as it comes with Windows.
I thought to create a gedcom and reload it into a second database to test the file integrity and now have some real digging in front of me based on the resulting file comparison.
Filename original.rmtree <> Filename GedcomLoad.mtree
People 12606 <> People 12606
Families 4344 <> Families 4344
Events 23056 <> Events 22390
Alt.Names 4777 <> Alt. Names 4777
Places 2331 <> Places 2310|
Sources 953 <> Sources 953|
Citations 11768 <> Citations 26481|
Repositories 146 <> Repositories 146
Media Items 1119 <> Media ltems 954
Media Links 1830 <> Media Links 14394
Addresses 13 <> Addresses 7
Tasks 133 <> Tasks 133
The fact that I ended up with more citations and media links than what I had originally is a real worry.
Since you are just testing, run the Sources => 3 Dots => Merge All Duplicate Citations tool in your database created via GEDCOM. I suspect your numbers for Citations still wonât match exactly, but that they will become much more closely aligned.
I canât determine the cause of the discrepancy in the Events counts in the abstract. I would need to have both databases to compare via SQLite. A possible cause is that you have a few fact types disabled for GEDCOM export.
The discrepancies in the Places, Media Items, and Address are very likely caused by unused items. GEDCOM will only include used items and not unused items.
Another probable is orphaned event records belonging to a now-deleted person or couple. They are now âunusedâ and not exported.
The mushrooming of Media Links is something that has been previously discussed but I do not recall the outcome. I think it, too is mainly related to what appears to be an unmerging of Citations in the GEDCOM transfer requiring additional Media Links to the duplicates. The âMerge All Duplicate Citationsâ tool should bring the Citation and MediaLink counts more in line with the source database.
The âMerge All Duplicate Citationsâ tool brought the Citations and Media Link counts to a little under the original.
However the speed issue persists. Just checked loading the same file on my ASUS Zenbook i7 2.8GHZ 16GB ram, and the same performance issues occur on it.
âŚand thatâs with all groups stripped out as a result of the GEDCOM transfer. Maybe RM Support should have a look at your database to see if there is something in it triggering unusual behaviour in the software.
I agree with Tom that you need to submit your database to RM for analysis. A common theme for users who have seen the speed issue opening a database is that they are using the problem alert list. I wonder if that might be the key to the problem.
1 Like
Likely a different cause for slow RM file opening in Windows and Mac. On the mac side I think it is just less than optimal programming and an Intel only code base.
Problem solved.
I had an unrelated database file containing 88K records which loaded in about 3 seconds, so it was evident that the 2 databases that I was using were the issue. As the smaller of the 2 was created as an extract of the larger via GEDCOM was the reason it also had the problem.
It turned out that the load performance was caused by TagTable DESCRIPTION field contained only 8 unique values, 6 of which were duplicated 386177 times each, with the other 2 values duplicated 368204 times each. In all a total of 3,089,470 erroneous records. Deleted them all and the problem was gone.
Similarly, hang time when closing the problem alert dialog was being caused by 23,703,020 records having a TASKID = 0 in the TaskLinkTable. Once deleted, problem fixed.
Thanks to all for your input, much appreciated.
Once more a happy lad.
1 Like
The Enhanced Database Properties tool does not go far enough. It could easily reporr the record count from every table and extremes such ss you had would readily jump out.
Next question is why did they happen? Something went gloriously wrong.
Exactly⌠what went wrong. I did have an issue some 2 years ago where I downloaded a file using Ancestry Tree Share in which for one record a single source returned 72 media items attached and 174 citations and this was reflected across many records. I have since migrated some of that file into the database in question and still cleaning up the mess. Maybe a legacy of that, who knows.