Annotative objects cause file save delay

[dkennard]

Hi All,

I have an native AutoCAD 2023 file "DRAWING_2" with some annotative blocks in it, which I reference (xref) into my current drawing "DRAWING_1".
As soon as I add "DRAWING_2" to my current drawing any save operation (qsave or autosave) takes over a long time to complete, locking the AutoCAD interface while the save operation is on-going. Windows Task Manager marks ACAD.EXE as "Not Responding" until the save operation completes.
If I remove the annotative blocks from "DRAWING_2" or detach/unload "DRAWING_2" from my current drawing everything is back to normal and save operations are near instantaneous.
I have to turn autosave off while working with "DRAWING_2" attached to my current drawing.
Note that "DRAWING_2" is not being changed or updated in the background.
I get the same behaviour if the files are stored locally on my workstation or accessed over the network.

I'd be interested to hear if anyone else has seen this type of behaviour. I have a case open with AutoDESK to see if they can replicate / cure the problem.

[Ed Jobe]

I don't know what you call a 'long time', but for me it only took 2-3 seconds.

[thomas.stright]

Autosave was the first thing we disabled in Autocad, Never seemed to work right IMHO.
I doubt this is your problem tho.

[Ed Jobe]

Autosave was the first thing we disabled in Autocad, Never seemed to work right IMHO.
I doubt this is your problem tho.

Maybe you just had a slow pc or slow network back then? Most pc's these days are plenty capable of handling save times in a responsive manner. I never had any problems with autosave. If you don't want to lose work in case of a crash, you either need to use autosave or manually do it yourself.

[thomas.stright]

If you don't want to lose work in case of a crash, you either need to use autosave or manually do it yourself.

Problem was when there was a crash all it produced was a zero byte file. And Yes, we manually saved regularly.

[Ed Jobe]

That's odd, because if it was saving each time it ran, then there would be a valid file. Again, I've never had a problem or heard of others with your problem.

[dkennard]

Thanks Ed, I'm getting a 20 to 30 second save time with this drawing. I can replicate the "error" condition on any machine (4 and counting) and AutoCAD version I've tried (2020, 2021, 2022, 2023 & 2024). I only see the condition if I have a large number of Annotative blocks in the Xref. Right now the only common factors in all the tests I've run are my corporate PC build (although different manufacturers and machine specs), and AutoCAD.

Below are steps to recreate the condition I see. I did this test on one of the slower machines with 10k annotative blocks and it took that machine almost 18minutes to complete the save operation (qsave).

1. Create 2 new blank drawing files using the ACAD.DWT template, let’s call these new files File_A and File_X.
2. Save and Close File_A and File_X.
3. Open File_X and create a block called ANNO_TEST with 1 attribute make the block annotative.
4. Insert the block and copy it a large number of times, I used ten thousand (10 000) in my test.
5. Save the drawing and close it.
6. Open File_A and attach File_X to it.
7. Save File_A (I see a large delay for this save operation)
8. Open File_X turn off the annotative property of the ANNO_TEST block. Save and Close File_X
9. In File_A reload the File_X reference.
10. Save File_A (no delay, this time)

I believe the relationship between the number of Annotative blocks and the time taken to save is linier. If I have 1000 blocks in File_X then File_A saves quicker than if File_X contains 2000 blocks.

[Ed Jobe]

What is a realistic number blocks for normal work? Do you normally use different scale layouts for the model? i.e. can you not use annotative objects?

[dkennard]

Yes sometimes, I would consider 10 000 to be an upper bound edge case, but yes around that number. Yes I use different scales for the layout and approaches so Annotative blocks appear to be the ideal solution.

In the past I've used non-annotative blocks at different scales to suit the layouts I'm using I'd put the different scaled blocks on different layers and turn on the layer I needed to see. This works well but is a pain if someone wants a sheet at a scale I've not setup.

The function of the blocks I'm using is to indicate chainage along a pipeline route, normally this would be 10 or so blocks per kilometre. In this case my client has a couple of different starting locations, a couple of different way points and a few different end points, all to be considered. The longest route is ~280km with all the combinations I end up with something like 60 route options giving me 8828 blocks.

[Ed Jobe]

That's quite a lot! Does the save time improve significantly if the fileA and fileX are on your C:\ drive instead of the network? I use Inventor and my assemblies of a substation contain thousands of parts. I have to work on the C drive because the network is too slow. A save could take a half hour, and we have a fiber network with 10gb speed. If working locally does not improve things, I would open a support ticket and ask if this is normal for annotative blocks.

[BlackBox]

<snip>
I have to work on the C drive because the network is too slow. A save could take a half hour, and we have a fiber network with 10gb speed.
<snip>


To help you appreciate what you've got:

My workstation (https://forums.augi.com/showthread.php?169462-Civil-3D-High-Performance-Workstations&p=1352591&viewfull=1#post1352591) runs at +/-20,657 MB/s (yes, big "B"), our server runs at +/- 40 Gb/s (12x of 32x drive bays filled in RAID 10, so faster with each pair added)... over a 1Gb network switch bottlenecking them... been asking for 10Gb network for years. :beer: :lol:

[Ed Jobe]

It could be 1GB, I can't remember. Regardless, I have to store files locally. Then I check them into the dms. For backup protection, I use Windows backup to copy my work area to another SSD.

[dkennard]

Yep, my save time improves a little but not significantly if I copy the files to my C: drive. I've opened a call with AutoDESK support and I'm working with them to replicate the issue, all the testing I'm doing is with files stored on the C: drive, to exclude the network from the possible causes. I cant think of a reason why saving my current drawing should not take longer if an attached XREF contains annotative blocks.

It makes me curious. What is AutoCAD actually doing during a save operation? In my over simplified view I'd assumed part of the benefit of the XREF was that, as far as my current drawing is concerned an XREF is just an insert point and scale the actual content of the reference does not matter, which is clearly not the case.

[Ed Jobe]

Yes, you are correct that the data for the xref is in drawing2.dwg. Each dwg file is a database. The only info that the parent dwg needs is the filename, insertion point, scale and rotation. It's possible though, that the parent file may need to store info regarding the annotative scale of the xref. With this plugin (https://github.com/gileCAD/Gile.Inspector/tree/master), you can inspect dwg objects.

[dkennard]

I did a bit of testing to try and capture exactly how long the save time is and what the difference is between annotative and non-annotative.
The test sets I used consisted of multiple versions of File_X with 1 to 3000 copies of the ANNO_TEST block, with and without the Annotative property set to yes.
The average QSAVE time of File_A for the non-annotative versions of File_X = 151ms, and 21765ms (~22 seconds) for the annotative version of File_X.

Graphed QSAVE times
109713

[dkennard]

I raised a support call with AutoDESK for this. The fix is to set the system variable SAVEFIDELITY to 0
The SAVEFIDELITY help page does not state what the default value is, so I'm not sure if I've set it to 1 or it's an out of the box default value.

[BlackBox]

SYSVDLG Command is your friend.