Rhino 6 - Slow save to network location

Thanks Chris,

Confirmed that Flow Control and Jumbo Packets have been disabled on the switch level. I might have to start thinking of it’s the existing system structure, as we are on DFS (not replication) and wondering of that’s the issue.

shrug + more testing…insert heavy sighs


we use DFS as well, for what it’s worth, we haven’t seen any performance issues…yet. Did you also try to disable flow control/jumbo packets at the workstation level? worth a shot?

@Cskills Something that just popped into my head is to see if there is a difference in times between:

  1. Reading an existing file, drawing a line, saving the file.

  2. Reading an existing file, drawing a line, using SaveAs to save the file in the same directory as the original but with a completely new name.

If there is an appreciable performance difference between these two tests and 2 is faster, then we could look at how we handle shuffling files around between a temporary, backup, and final result.

Gonna try that now on a couple of systems to see how that will work. Will keep you posted.

ok, good luck! These are never fun things to troubleshoot. but a few orders of operation that we have found helpful, (in situations where network speed seems to be troublesome).
Specific to Windows Servers running DFS: the usual suspects are updates, reboots, blah blah.
Also, if any of your dfs targets are ISCSI, (and attached to your DFS server)…definitely turn off the following items on the NIC of the DFS Server, (especially if it’s a broadcom adapter), heck, you might want to try these even if it’s not ISCSI.:
Flow Control
Interrupt Moderation
Large SendOffload (IPv4 and IPv6)
Receive Side Scaling
TCP/UDP CheckSum Offload (IPv4 and IPv6)
Virtual Machine Queues

you said you aren’t using DFSR, so I will assume that this isn’t a “wrong site target issue”.

All of this is just recommendations, they do not require reboots, but obviously will drop the network connection when you make changes, so…don’t do these on the server during production.

Lastly…This is NOT to say that Rhino 6 ISN"T the culprit. Just a few other items to consider.

1 Like

So after checking on our VMs and setup, it looks like VMQ was the issue.

Granted I’ve only done a couple of test, but the results are night and day.

Did a save as with VMQ enabled, and it was at least 45mins.

Did a save as with VMQ disabled, and it completed at 5mins.

/me: smacks myself for the little things…

Thank you all for the assist and beers on me @chanley!

1 Like

@Cskills, @chanley

Cskills, I’m glad to hear that you made some improvements by adjusting network settings. It would be nice if we could modify Rhino so it wouldn’t be so sensitive to “VMQ” settings and I’ve added this information to our internal bug report.

Thank you all for using Rhino and sharing what you’ve learned in this forum.

– Dale Lear

For what it’s worth, The only time I have seen the VMQ setting make a difference is on a windows 2008, (or up), server, with a broadcom adapter.

Rhino 6 is slow not only to network location but so at external HDD via USB 3.0 or HDD internal SATA 6 Gbs
… I testing opening the same file duplicated . Rhino 5 in one screen vs Rhino 6 at second screen. Rhino 5 wins always.
Any workaround…?

Hi Dale,

I’ve been having this slow save issue since Rhino 5. I was hoping Rhino 6 would remedy this, we ugraded to 6 very shortly after it launched. I’ve had a lot of time to experience different files. Saving is consistently slower than other programs either to desktop or to the server. This is not just my computer, its our whole office. We are all saving to a server with SDDs, the server is running Windows Server 2016 Essentials. Its very fast for other tasks and other programs, but Rhino is very slow.

I did try your suggestion to " type the command SetArchiveMemoryBufferSize and enter 32000".

Here are a bunch of test with a large Rhino file (950 MB) and a large Photoshop file (996 MB). We generate a ton of large files, so every second in saving matters.

Rhino 6 File - 951 MB (997,403,500 bytes)
2:15 save from rhino to server
2:08 saveas from rhino to server
0:40 save from rhino to desktop
0:08 copy file from desktop to server
1:07 SetArchiveMemoryBufferSize to 32000 (Checked save textures)
1:02 SetArchiveMemoryBufferSize to 32000 (Un-Checked save textures)

Photoshop CS6 File - 996 MB (1,045,361,300 bytes)
0:24 save from photoshop to server
0:14 save to desktop
0:10 copy file from desktop to server

I’ve run these comparative tests before, this is the first time I tried it with the SetArchiveMemoryBufferSize. To me this is a Rhino problem, not a server problem. This conclusion is based on the comparative saves to desktop, and the saves from Photoshop to the desktop and server.

The Memory Buffer setting does help, it cuts the save time in half. I’d love to get it down to the level where it is comprable to Photoshop. The other thing that Adobe does is it lets you keep working while the Photoshop file saves in the background. This is also enormously helpful.

Thanks for the Memory Buffer suggestion! Let us know if you have any other Rhino fixes that could help, or hopefully Rhino 7 will address this.

Hello - we did find that for large files the time spent compressing starts to be overwhelmingly more than the save - In v7/WIP there is an advanced option to turn off compression, which may or may not help here, but just fyi…


Just did the same bench-marking with Rhino 7 WIP, here are the results:

Rhino V7 - Same file used - 951 MB (997,403,500 bytes)
2:14 save from Rhino to Server - Use Compression True - Size Result 952 MB (998,406,762 bytes)
1:50 save from Rhino to Server - Use Compression False - Size Result 1.09 GB (1,180,953,316 bytes)
1:09 save from Rhino to Server - SetArchiveMemoryBufferSize to 32000
0:35 save from Rhino to Server - SetArchiveMemoryBufferSize to 32000 and Use Compression False
0:12 save to desktop (WOW!!!) - SetArchiveMemoryBufferSize to 32000 and Use Compression False

The implications of not using compression is files that are 18% bigger. I think we’d likely turn compression off, however 18% is not insignificant.

It would be ideal if Rhino could save in the background so we could continue to work while saving, and not have larger files due to disabling of compression. The good news in disabling compression is that it really starts to let us realize the advantages of the SSDs that we put into our server.

Is possible to use this also in rh6?
We can save muche time specially in big file.


Hi Marco - no, this is new in Rhino 7.

I understand.
But the difference with or without compession specially when you have large file with mesh is impressive!!

Sometime I save the file during coffe break, locally and is a file of 230mb.


Just to aunderstand.
How long you take to save this file?
It takes more than 2 minutes. What’s wrong?

Rhino 6 last release local ssd



Can you see my file, I’ve uploaded twice.


Hi Marco - no, there is no file visible here.
If it’s a large file you could try uploading it on this page - make sure to put the URL to this discussion in the comments field.

I’m Uploading, whith the link at this discourse discussion.
Now I’ve partially resolve removing this option.

rh6 about 20 sec.
rh7 without compression some second.


Hi Marco - if I understand you correctly, there must be something else going on on your system.
Rhino 6 saves that file in 16 seconds on my C:\ drive with contents indexing turned on.

Or was it the compression option that you turned off?