You might realise an order-of-magnitude improvement by going to the highest-end processors available but they cost over $1k. Some benchmark comparisons show a ten-fold superiority for the i9-13900K over your current processor but not for all tests. We don’t know which would be relevant. Should you have to pay $000’s to get the performance you need out of some cheap software?
I can’t imagine that TreeShare is viable for you at 400k population and I would not suggest that FTM2019 would be any better at working with an Ancestry copy of your database. So maybe you should be looking at alternative software that has no similar Ancestry capability but is efficient at working on a huge database. I opened this 200k database in FH7 and detect no lags in bouncing around in it. I was going to try Heredis 2023 but it looks like it could take an hour to import a 200k person GEDCOM (I don’t remember how long it took FH7 to import the RM database file directly - that was some time ago). You might settle on one of these as your primary software but no one program is likely to have all the features you want, especially outputs such as charts or reports, in which case you might explore exporting from your working software to the secondary to exploit its features.
[quote=“JustinHouser, post:37, topic:8458”] quoting Diana of RM Support:
I did see it is a little slower than other files I have tested, but thing out of the ordinary.
[/quote]
So “ordinary” is multiple seconds to tens of seconds pauses in even trivial workflows on large databases. This has nothing to do with the SQLite database engine and everything to do with the software that interacts with it. It is “extraordinary” and unacceptable.
RM9 is certainly very much slower than RM7 at doing the same things with the same database engine. Its sluggish performance has to be due to one or more of program design, development platform, cross-platform overhead, … Surely, the legacy Windows user community is not now suffering from some intermediary translator of Esperanto instructions made necessary by the native Mac product!
I’d greatly appreciate your taking a look at it. Please let me know how I could get it to you – some kind of Google Drive or Dropbox upload, I suppose. Whatever is most convenient.
Thank you for this! It is very understandable to me and I understand what you are saying.
I agree that, whatever RM9 is doing in this scenario, it is very inefficient. Just wish we could tell what it was doing and see if it could perhaps be fixed in an upgrade or update.
Ancestral Quest didn’t have this problem and I liked it very much. The only reason I switched to RM earlier this year is because I wanted a program that could sync with my Ancestry tree and upload photographs, etc., to Ancestry without much effort, so that they showed as actual profile pics there. All of my DNA tests are linked to my Ancestry tree and it is a pain to have to re-link and re-do profile pics every time I upload a more recent version to my tree.
Don’t blame the mac version for slow performance. RM9 is intel only code and has to go through Rosetta translation for Apple silicon. Despite chips with 10x x86 performance RM9 still takes 20% CPU at idle. All 27 of my native apps use much less than 1% and even Doxie (1GB intel) runs at 5%.
I think we are all experiencing less than optimal programming which may improve over time as kinks are found and removed.
I’m a Windows user, but even so I have wondered about that. A good compiler should be able to compile to more than one hardware platform. Doing so should eliminate the Rosetta translation.
Must not be the case since Apple bothered to write Rosetta. Apple’s new chip design is RISC AMD based and puts all of the components on the chip with very short connections (1/10 power draw and heat=fanless design) and RAM shared between cpu gpu etc. These chips are also 5nm going to 4 next year. Some major Intel only programs actually run faster on Apple chips despite translation but not RM9.
Actually it is the case. Embarcadero Delphi, which has been put forth as the development tool of choice for RM, does indeed compile to native M1 code and has for at least the last 2 or 3 years. Presumably it will also compile for future MX versions since Macs aren’t going to go back to Intel.
I would venture to guess that when RM8 came out, RM banked on the fact that most people were still running Intel chipsets and so they targeted development towards that segment.
RM probably has so few mac customers left that coding for that market is a poor use of their limited resources better focused on fixing the current product for Windows users. However all my mac apps except RM9 are now either Universal (Intel+ M1) or Apple Silicon (M1).
Let’s not get hung up on PC or Mac Intel code. Yes, the development platform today creates either Windows Intel code or Mac Intel code, but getting the former significantly improved might/should rub off on the latter.
The discussion earlier has highlighted what seems to be an extreme case of excessive I/O or CPU (or both) in what should have been a very quick operation. There are other areas where things are surprisingly slow and seem to consume what seem to be excessive amounts of resource. Surely we need RM to focus on such examples to try to discover what on earth the code is doing and whether there is some way of improving matters. I suspect that improving matters in one case would also improve other areas.
I’ve had a look at your database and reported to you privately that it behaved on my older, slower i5-based Win 10 laptop as I expected - some 20s from closing the Edit Person screen with no changes in data to getting a response from clicking on a different person in the unfiltered sidebar Index. Compared to yours:
Tonight I looked at it further with my own ‘enhanced properties’ SQLite query which showed nothing obviously out-of-the-ordinary. Of course, with 400k person records in your database, some tables are unusually large but that should not matter a great deal. Furthermore, I converted your RM9 database to RM7 and confirmed that it allows almost instantaneous switching to a different person on closing the unedited Edit Person window. It is entirely a software inefficiency issue in RM9, not your database, that is the source of your problem.
BTW, the title of this discussion is probably misleading or too narrow in scope. In my test, no data is being saved; it is merely navigating through the program. Maybe it should be changed to something like “Operations VERY slow…”.
My “quick and dirty” secondary research tree has 738,000 people. I use a mix of PCs, laptops, a Mac Mini, and an iMac. My main PC has a dual core I3-1005G1 @1.2GHz (turbo 3.4GHz) with 12GB of . This is a little slower than both your PCs. Interestingly I hadn’t independently noticed this issue. But … when I open the Edit Person window on this large tree i see a CPU spike for a second. When I close the window without changing I see a 35 second burst of CPU to 90%. Note that I have only two physical cores (four hyperthreaded).
