Insanely Long Save Times (Assemblies mostly)

[RNDinov8r]

So, I have a few users where saving a top level (full machine assembly) is taking 40 minutes. We work on all of our files over a network. This same file could have an update undone, then reapplied, and the save would take 30 seconds.

1. We're not using Vault - will eventually switch, but not an immediate solution, so don't suggest it. We know it will resolve a number of issues...however, this issue seems to be something outside of what vault would fix (see item 4)
2. We are running 2020.4.1 and all machines are up to date.
3. Without posting all specs on computers, these are more than capable work stations, and using Niels newest Benchmarking app, they are clocking in a few points under epic, so not a hardware issue that I can think of.
4. It's random...sometimes an assembly will take a long time, and sometimes not...and it's not saving all the sub components either, it is literally just the top level assembly.
5. We use  constraints, not joints. I've heard this helps with file size, however, is this really the issue?
6. With my IT guy at my side, we watched a large assembly save in real time and monitored the network traffic/stress....barely anything at all...so, it points to the fact that the network itself should be able to handle the bandwidth.

[CGBenner]

@RNDinov8r 

Very thorough post!  Thanks for all of the information.  Curious:  In the instances where this is ocurring, are there any common denominators, such as common components or subassemblies involved?  Anything that could potentially narrow this down to maybe one bad part or sub?  

[RNDinov8r]

we have not noticed any commonalities. For example, I can open the same file, make the same changes (as a matter of testing) and have no issues.

[johnsonshiue]

Hi Chad,

The quickest thing to check is "Express mode." Go to Tools -> App options -> Assembly -> uncheck "Enable Express mode." This option is supposed to help boost large assembly performance by storing cache graphics in the top-level assembly. When you open the large assembly, only the graphics will be shown and the component documents will be loaded on demand (when being edited).

However, it will prolong the file save. It is because the graphics segment can be large. Also, the need to save cache graphics is an additional tax you pay when saving files. Depending on the complexity of the geometry, the cache graphics can take up significant time and space to save. Also, we notice that if you have several Decal features in the part, Express mode save does take much longer than non-Express mode.

For your purpose, with decent hardware, I don't think you need the option enabled. Simply turn it off and you will see the iam file becomes smaller and save becomes faster.

Many thanks!

[RNDinov8r]

Johnson, we disabled express mode the day we installed the software. No one here is using it as far as I know. I will verify this. Since I created the Application Options Settings XML file that everyone else uses, and I have files set to open in Full, I doubt this is the issue.

[johnsonshiue]

Hi Chad,

If "Express mode" wasn't used, this could be related to network. Try using Microsoft Process Explorer or Process Monitor to see what really happens behind the scene.

Many thanks!

[RNDinov8r]

Johnson, that's the thing, we have. My IT guy and I watched a save occur and nothing was out of the ordinary. Even RAM and processor usage was low...

[Frederick_Law]

---

@RNDinov8r wrote:

Johnson, that's the thing, we have. My IT guy and I watched a save occur and nothing was out of the ordinary. Even RAM and processor usage was low...

---

Could be because IV is waiting on network respond.  A lost packet, bad CRC, latency, delay reply will add up really fast on access time.

Another test.  Copy all files to local drive and see if it's slow.  If not, 100% network.

Remember, for each file opened, Windows create a hidden lock file to track users.

For each save, IV create a temp file for new save, move old one to OldVersions, rename new save.

Add 30 sec timeout to each step and you will be waiting forever.

I've only seen less than a handful of IT that can set the network right.

[RNDinov8r]

Pineapple, do you happen to know of specific network settings we should be looking at? I am pretty confident in our IT guy. One of our problems is that curretnly, we are under contract with anothoer offsite IT firm (for another month or so) that is managing a lot of stuff. We don't know what they are doing in all cases with files and folders...(this is the short explanation) I am out of the office this week on vacation, so don't have a chance to test the local drive...being 1000 miles from my work station, even remote log-in is a tad laggy with the mouse. 

[Frederick_Law]

My experience was on XP and Windows 2000 server.
One of them was to turn off error check which made our ERP usable for 5 people.

There only a handful in the forum that can run IV on network without problem.

Vault does help to reduce network traffic by keeping file local and sync when needed.

And the current remote/VPN connection is completely different.

[RNDinov8r]

Error checking? is that within the AutoDESK application or the Server side? I realize we're not using 2000 anymore, but something worth investigating.

[Frederick_Law]

It is Windows network setting which is changed in registry.
I should have the reg file somewhere.
I haven't found anything when Google for Windows 10 network  optimization.

[Frederick_Law]

https://www.speedguide.net/downloads.php

Found this.

They have a few articles.  See if any of them helps.

[CamperUnhappy]

I also experience the same thing when working with a large assembly.  When I go to save the file and multiple parts have been edited inside the assembly......I might as well get up from my desk and go for a walk.

I have analyzed the load on the network and there is very little actual data being sent.  My IT guy has reassured me that the network hardware is not the issue.  Maybe it is something to do with error-checking or scanning as was earlier stated.  I've forwarded this post to my IT guy to have a look at and offer any suggestions.

I'm hoping we can move to Vault soon, but I'm pretty much the only one who wants to add this level of complication to my work flow........however, I'm the guy at my office that generally has the largest projects to work on.

[Frederick_Law]

If possible, have IT monitor what happen and how long each step took.

Open an assembly.  Get a list of files got send over and how long it took.

Modify/rebuild the assembly.  Save the assembly.
Again monitor how many files are saved on the server and how long.

[johan.degreef]

Try to disconnect from the internet in any way, wired & wireless. Try if it becomes fast now.

[RNDinov8r]

OK, so we did a little digging, and it appears that the one work station was running a very old version of iPropWiz6...I am not sure why it wasn't running a newer version, but in any case, after removing the add-in, so far Inventor is saving quicker. Still testing to see if that was truly the issue...because we have other people using different versions that do and dont' see the save time issue.

@phlyx ran a test on a new assembly (original file wiht a new name) and found that the network was hitting 300-350 mb/sec and saved the file in 16 seconds....but on the original assembly when saving, we noted that data transfer rate was in the 10 mb/sec rate - if i correctly recall - (last time we checked a couple months ago).

[Frederick_Law]

Try disable all addin and compare.

[phlyx]

Well, it looks like iPropWiz might not be the root of the problem.  Just now the engineer that had the problems saved the same assembly and it took about ten minutes withOUT iPropWiz installed at all.  I did a Task Manager/Performance check and CPU was very low, disk very low, but ethernet was jumping all around.  When I was saving the file my network was throwing data at +300mbps but on his it was bouncing between 20-40mbps.  That would make sense if the network traffic was extremely throttled down the same data would take a LOT longer.  Still looking but iPropWiz was found not-guilty  😊

[phlyx]

Also, a side note along this same line.  I work on several large machine assemblies and first thing in the morning, when I have a large machine assembly open, I can switch between tabs and click something (a command or select something in the model) and it will be +30 seconds before the command starts or the item highlights.  Click to a different tab and +30 seconds.... click back to the first tab and +30 seconds.  But the odd thing is by the end of the day I can change tabs and pick things pretty much instantly.  I don't have to have those particular assemblies open a long time, just have to have Inventor running a long time.

The machine I was working on this morning with the 30 second lags I just opened with some other assemblies and changing tabs and I can pick something and it's instant.   I shut down all the assemblies and closed my Inventor session and re-started it.  Opened the same assemblies switched tabs and clicked on something, 36 seconds to highlight.  Switched to another tab with a smaller assembly and clicked on something, 12 seconds to highlight.   Switched back to the big assembly and clicked something, 42 seconds to highlight.  Once the lag times out everything in that model is quick, but switching tabs and I get the lag before I can do anything.  I don't have to click anything, it will just be hung until it times out.  About 10 seconds after I switch to the large assembly I will also get the spinning wheel for a second and the top bar will flash (not responding).  

I can keep Inventor open all day and by the end of the day there won't be any lag.   Weird.