Hi @pascal ,
I suppose so you got my example file. I have a new information for this issue - if I use incremental save instead save than the scene is saved in 38s instead 8:30min.
I hope the save time can be nearly so fast like incremental save.
Best -
Micha
Hi Pascal,
the option was disabled and I disabled it now. The save time is ~6min, still much to slow.
Micha
Great, this bring down the time a lot. Only could I get both - a small file size and a fast save? 8 min for compression looks like something is wrong.
Why was the incremental save so much faster than the standard save? Are not both using compression?
@pascal Something is not working properly. When I turn off compression, standard storage is fast like incremental storage, but incremental storage is much smaller than standard storage.
Simple test - I save my current project with incremental storage: after a few seconds I get 1250 MB. Now I save the file with standard memory: after a few seconds I get 1800MB.
So, turning off compression is not a solution, incremetal save shows that speed and high compression are possible in combination.
It would be nice if we could find out what is going wrong here. Or is someone else from the team the better contact?
Iām going to hasard a guess hereā¦
The normal Rhino āSaveā function works like this - for a file that has been saved at least once:
IncrementalSave, as it is saving the current state of the file as a new file, does not need to write the temp file and check/rename it to the original name afterward. It just simply saves the file. So maybe the time problem is steps 2 and 3 above, especially if the file has compression enabled.
Thatās my theory at least, but I could be way off in left field.
Iām curious for someone of the McNeel team who will test it and found the reason for the big difference (save is more than 10 times slower than incremental save).
I doubt theyāre seeing it, or other people would be seeing it too. Iāve never seen such a thing, Iāve seen kind of the opposite, but that was until I figured out how to make IncrementalSave use SaveSmall.
I got an idea and I did some more tests - I found the problem was that āsave texturesā was enabled. Maybe incremental save doesnāt save textures. I suppose so the texture collecting progress is so horrible slow.
Itās a pitfall - if I open a new Rhino task and try to save the scene than āsave texturesā is automatic enabled. Nearly never I need this function and so I must careful disable it always. Iām working on very large files and this option cause a slow down and that the hard disk is faster filled.
Iām glad to have a solution now. 
@pascal Is āsave texturesā enabled per Rhino default or is it at my machine only? I think this options should be disabled per default.
It seems to be a default for new files. Maybe itās in the template? Yeah I donāt recommend using it by default either, yes it was years ago I was in a situation where it was āneededā but it was not reliable.
I thought it was supposed to remember the last used settingā¦
It does for a particular file, but new files have it on by defaultā¦so maybe itās a document setting thatās saved in the template?
Hi Micha - There used to be a setting in Document Propertiesā¦ it was removed because, āwhen would you not want to save the textures?ā Well, in general, why not, but this would be a caseā¦ I still think it is the exception to have files with so many or so large textures that it is a problem. (PBRs may change that)
In the meantime, if you -Save you can set that even after the file has been saved - is that not sufficient?
-Pascal
Yes, for me itās ok to disable it all the time. Itās one more thing I have to keep in mind 
I see no reason to always save the textures in a Rhino file. The textures are on my hard drive and I only save them to the file when I need to send a Rhino file with textures to a client. But thatās not necessary on a daily basis. But daily I have to save my work.
My needs are a fast save and not so big Rhino files.
Hi Micha - I guess the underlying thought is that it makes file sharing a mess if textures are not saved by default, and that would be a far more common problem.
@Micha - I understand it is a bit awkward - for now, you can make an alias or button that has -_Save _SaveTextures=_No and click on Browse at the command line the first time a file is saved.
-Pascal
Sureā¦but it inflates file sizes (which does matter with SSDs or network locations,) leaves extraneous temp files scattered around, and my experience saving textures a while back is that sooner or later Rhino will lose track of them and you have to rebuild all your materials.
If we look at say, InDesign, which is all about linked external files and the workflow of passing things along to other people, it doesnāt normally embed anything unless you explicitly do it, and when you want to package everything up to send downstream thereās a separate command for that.
Hi Jim - I can imagine it may need fixing, but as a default, it still seems more certain to work. If I were king, I would simply restore the document setting, then it could be in a template, and for the most part weād be done. Iāll see what we can do.
@Micha - if you use -_SaveAsTemplate it looks like you can make a template that works as you want.
-Pascal
@pascal One more thought - could it be that the code for packing the textures is unusual slow? All textures are opened at the current scene. Also starting a rendering doeās need so much time (in this case all textures are loaded too), so why is saving with textures so extreme slow?
Thank you for the hint with the template.
