Loading and saving the accounts XML in 2.6 was fast, 3.1 was slower, and every version since then (including 3.5) has been almost unbearable. However, minimizing the main window makes saving the file extremely fast. Similarly, dismissing the startup window on OS X (by simply clicking on it) makes the load time a few seconds. My accounts file is 2.4M. I'm on a 2008 Mac Pro w/ OS X 10.11.6 and two 1080p screens, so HDPI should not be in play in my setup. On my 2017 MacBook with MacOS 10.14 and a Retina display (HDPI), load/save behaves as fast as expected. This seems somewhat similar to Bug 795804 on Windows, but opposite: HDPI may result in fast load/save, while standard DPI results in slow load/save. I'd love to help test patches, etc., but getting a build environment setup in OS X for Gtk and Gnucash is...challenging. If anyone has any pointers on getting a build environment setup, I'd love to hear them. Steps to Reproduce: 1. On Mac, load and save a 2M file on a standard DPI screen. Actual results: Both operations are very slow. Expected results: Load/Save times of 10-15 seconds, similar to those experienced on a HDPI screen. Build date: Gnucash 3.2 release up through Gnucash 3.5 release.
I don't see a noticeable difference between my 2014 Mac Book Pro Retina and 2013 Mac Pro with a 54M book. Perhaps something else is going on. There's a nice and easy to use profiler as part of Instruments. Try using that on each machine to quantify and perhaps identify the source of the difference. There are two fairly straightforward ways to get a build environment for GnuCash: MacPorts [1] and gtk-osx [2]. [1] https://wiki.gnucash.org/wiki/MacOS/MacPortsDetail [2] https://wiki.gnucash.org/wiki/MacOS/Quartz Both are in need of updating but should be enough to get you started. The latest and therefore most correct getting started instructions for gtk-osx are in the README, see https://gitlab.gnome.org/GNOME/gtk-osx.
I am (and have been) experiencing the same problem (also commented in https://bugs.gnucash.org/show_bug.cgi?id=795804#c36; not sure why that bug is marked resolved). I just tried again with v3.5 hoping that the issue might have been addressed, and also upgraded my v2 to 2.6.21). Conclusion remains the same: the 2.x version is ok, but 3.x results in Load/Save times upwards of 5 minutes. Clicking away the splash screen and minimizing the window as the OP suggests, does work and reduces Load/Save to seconds. I'm on a late 2013 MBP retina running OSX 10.11.6.
Bug 795804 is resolved because it's a Windows bug and we resolved the issues sufficiently on Windows that the OP was satisfied. Do you have many tabs, especially reports, open?
No - even with no tabs open, same result. The splash screen now spends 6 mins in the "Loading user data" phase; if however I click that away (never realized you could do that); or disable it in Preferences, reading the data files takes under 10s. For it to be useable I have to still minimize the window when the autosave kicks in.
That 54M file I mentioned in comment 1 takes 12-15 seconds to load on both the MacPro and MacBook Pro; these are running 10.14.5 and 10.14.6(beta) respectively. In both cases the file is on an SSD. I tried a "save as" to an old thumb drive; that slowed the save down to 36 seconds, but Instruments showed that it was, as expected, waiting for the drive. The CPU time was 6.5 seconds. I also tried putting GnuCash in full-screen to see if that made a difference. It didn't. Next I fired up a 10.11.6 VM and installed Xcode and GnuCash-3.5 on it. Slightly slower, it takes 20 seconds to load the file. The profiler shows that GnuCash is spending a little time (3 - 4 seconds) in gnc_window_show_progress, which updates the progress bar. I'd like to see what's different on your machines so please do the following: Open Xcode and select "Open Developer Tool>Instruments.app" from the Xcode menu. That will present a dialog box. Double click Time Profiler. When the window opens you'll see a record and pause button and a large button with an iMac icon and your computer's name. Click the last button and select [computer name]>Choose Target... from the context menu. Select Applications:GnuCash.app from the file chooser dialog and click Choose. Click the red record button. It will prompt you for your password then GnuCash will start. It may take even longer to load your file than usual. When the file is loaded, edit something and save. When that's done quit GnuCash. Save the file with File>Save. Give it a memorable name and attach it here. N.B. If you haven't already installed Xcode you'll have to get it from https://download.developer.apple.com/Developer_Tools/Xcode_7.3.1/Xcode_7.3.1.dmg, the App Store has only the latest version for Mojave; that won't run on El Cap. You may need to sign in with your Apple ID.
Created attachment 373283 [details] XCode/GnuCash3.5 run with main window open
Created attachment 373284 [details] XCode/GnuCash3.5 run with main window minimized
I've attached two runs as you suggest; one with it saving with the main window open (total runtime 8.5min), one with the main window minimized during the save/exit (total runtime 47s). I went down the call stack while comparing these runs, and ended up with gtk_css_gadget_draw as a possible culprit. Hope this helps - happy to try something else.
Created attachment 373285 [details] Profile trace GnuCash 3.5 in 10.12 VM Here's a run from my 10.12.6 VM. I used that because it has the version of instruments that would load your traces, so I hope you'll be able to read this one. The results were similar on a 10.11.6 VM. I had the splash screen turned on and left the window maximized during the save. Load is between 00:22.2 and 00:47.2, save is between 00:56.0 and 01:22.50. Notice particularly the high CPU loading during load and the last 3rd of save, ~75%; even in the lower-usage part of save it's around 15%. In contrast the CPU load during your 6 minute save is only 3% but with the window minimized the save took only two clock seconds and the utilization is %130. I think that's telling us that there's some sort of display synchronization in your computer and gdk-quartz is getting something wrong so it's blocking.
