I'm just exporting a GEDCOM to disk. It's not going anywhere on the Internet. Are you doing something that sends your GEDCOM to the Internet?
The result is going straight to disk.
Interesting on the 32 bit - I had that column excluded in my activity monitor. Mostly 32 bit here as well.
I would actually love it if someone could point me to a problem where my system disk writes could be sped up by several orders of magnitude, but I don't even consider it worth talking about. I am otherwise quite happy (might I say amazed) by the system performance I get from these systems. I decided to load up my Windows 10 VM, and load Roots Magic there as well. I have an "old" 110,000 person version of the tree there from FTM 2014 that loaded up in ~ 20 minutes vs. 1 hour and 13 minutes for the 145,000 person tree on my MAC. I started the export at 7:37 PM just after the import finished and it stands at 3960 people while the MAC export I also have running for significantly longer is at 1840 people. On Windows, that's ~153 minutes for now and 4000 people and change =~ 26.14 people/minute. This is well over a 5X speedup. The wine crossover processing for MAC-ifying is consuming at 32 % of a core, and RM7 is consuming ~ 70%. With Unix, that's about as close as it will keep things to 100 % in my observation. Total CPU usage for my system - including RM7 on OS X exporting it's heart out, RM7 on a Fusion Windows 10 Virtual Machine exporting it's heart out, an Ubuntu Linux Fusion VM running PostgreSQL, and an assortment of other processes including a development web server... You get the idea. I will say my fan doesn't usually run but I can hear it on low cooling the CPU a tiny bit running at a 27-33 % load with no bottlenecks.
On Windows 10, RM7 is using 54.3 % of available CPU "space," and the disk is swapping between 0MB/s and 0.1MB/s - oh, and 8 MB of memory. I am sure there are other explanations for this behavior, but the way I would likely read it until proven otherwise is that the DB can't keep up with the CPU. Overall the disk is toggling between 0% and 1%, Memory at 54 % and CPU at 56%. I just checked, and my windows instance has 2 cores and 4 GB of RAM allocated. By the way, I'm not seeing where it is favoring one CPU over the other - they seem to be operating just about in lockstep. I don't see where Resource Monitor talks about 32 bit vs. 64 bit, but I think this is probably something that can be ignored. Without the wine crossover processing, Windows is giving it quite a bit more processing - they are the same processors. If the application is somehow limiting to roughly 1 CPU worth of processor cores, then this could be an alternate explanation I guess. I think one of the things I noticed when I converted FTM 2014 over to Windows 10 was how much better 10 handled multiprocessing, but I don't have data. What I do know is that I went from almost never being able to SYNC this tree to often being able to SYNC this tree - it was a highly significant improvement. FTM3 for MAC SYNCs pretty much every time, but if I wait too long and my wife adds too many records it can get confused enough where I judge it's time to start from scratch - which is VERY painful but pretty reliable.
If you are hearing that this has been a bit of a problem tree, you would be hearing right. BUT, NO ONE has ever said there is a problem with it other than it is "too large" to be handled gracefully between FTM and Ancestry. I'll give it to Ancestry that they didn't boot us out, but we did get pretty frustrated with each other at times. It got pretty tiresome to start every interaction by reaching out to a first level phone support person every time and justify taking up their time. I think I've finally figured out that the way to avoid some of this is a well thought out email to firstname.lastname@example.org, but even then one or the other of us would have to jump through hoops because our problems were almost never the easy problems.
I have a few smaller/simpler trees, so I imagine I'll import and export one of those just to show that it's NOT my system conclusively and then we can stop the largely useless discussion (and I greatly appreciate your part in it!) and get back to what is actually happening.
It might be interesting for the RM7 folks if you could also summarize your record counts like I did so that they can use your tree as a data point if they need to. If your tree is - say - 500,000 "records", then dealing with the linkages between those vs. dealing with the linkages between 2,400,000 "records" can be huge (probable exponential relationships which are a possible explanation for what I am seeing) depending upon where you run your software relative to inflection points. It is always a balance and unless you really know what you are doing - which I am still learning - then things can pop up and you have to work hard to beat them back down (read speed things up). RM7 import speed - acceptable. Responsiveness after import - excellent so far but I've spent most of the time I could be exploring defending myself. Export - disaster for this tree, and so far it appears it is only this tree. Like I said, I hope someone tells me how I can get a 10,000X improvement in disk write speed. That would actually be dramatically better for me than being right about database thrashing (I don't believe in that kind of magic though).