An Auto Save in Rhino for Mac happens in three phases.
The first phase is initiated by the Apple frameworks. Some time after a Rhino model has been changed, the Apple frameworks decide it is time to start an Auto Save. The Apple frameworks initiate an Auto Save when you switch to another application. It will also initiate an Auto Save when enough time has passed (this seems to be about five minutes) and the program seems idle, i.e., no recent mouse movement or typing. If you constantly move the mouse, an Auto Save will never start. When the Apple framework initiates this first phase, it asks Rhino if it is OK to Auto Save at that moment. If Rhino is in the middle of a command, Rhino will refuse the Auto Save, and the Auto Save operation is abandoned. If Rhino says it is OK to Auto Save, then the second phase is initiated.
In the second phase of an Auto Save, the user interface is locked and the Rhino model is saved to an in-memory buffer. No disk activity occurs – this is an entirely in-memory operation. This creates a special copy of the 3DM model. No render meshes are written to the in memory buffer, which saves considerable space and time in creating the Auto Save version of the model. When the in-memory copy is finished, the user interface is unlocked and Auto Save proceeds to phase three. Note that the user interface is locked during this phase to prevent you from changing the Rhino model while it is being copied.
In phase three, the in-memory buffer is passed to a background thread that then writes the in-memory buffer to disk. Because this is running in a background thread, it can take as long as necessary and it will not block Rhino from running.
These three separate phases allow you to have your model on a very slow disk that is Mac file system compatible (HFS+), and you will not experience any Auto Save slowdowns. For example, Rhino files on Mac compatible network drives work fine with Auto Save. I have formatted a thumb drive as HFS+ and put 3DM models on the thumb drive. Rhino will perform Auto Saves to the thumb drive and I was not blocked at all when Auto Save runs. I could also see that writing the 3DM file took perhaps 10 seconds to complete, but this happened on a background thread and did not keep me from modeling in Rhino while that happened.
I tried duplicating the issues described in this thread. In a new model I created an array of 25 x 25 x 25 spheres. This is 15,625 objects. Each sphere takes 1152 polygons to mesh. (I wanted this to be a torture test.) I assigned a material to about a third of them to imitate the problematic model described above.
When I save this model using the normal File > Save, the 3DM file is about 465 MB and takes more than two minutes to save. Almost all of that time is spent compressing the meshes.
When Auto Save runs, no meshes are saved. The 3DM file that is saved is about 50 MB, and phase two of the Auto Save (when the user interface is locked) takes 0.7 seconds. If I removed all the material assignments in this model, I saved about 0.01 second in the Auto Save. The number of materials do not seem to be a factor.
I did discover one inefficiency in the Auto Save. The preview image is saved in the Auto Save version and is compressed. That compression operation added a full second to the second phase, more than doubling the time the user interface is locked. This will be fixed in the next WIP release.
These tests were run on OS X 10.10.5.
I am unable to duplicate long pauses while Auto Save is happening. Perhaps there is something else in Zsimon’s model that is causing a slowdown. I’ll need to get a copy of that specific model to duplicate it. Go to the McNeel File Upload web page. Enter your information and use marlin@mcneel.com as the recipient address at McNeel, and I can try duplicating this issue.