Topic: Autocad / Civil3d loading performance monitoring

[cb]

Hello,

First I would like to say thank you and hello for all the help I have received just by lurking around.  This site has been and continues to be a great resource.  Sure I could ask my question to ADN etc... but I really value the knowledge you all share.

My situation is this.  I am above the scary curve with c# and .net.  Still have a lot to learn but capable of getting most things I need accomplished.  With that being said.  I am clueless as to understanding enough to know what we need can be accomplished.  We have recently had some issues here at work with our file server, user error in setting up efficient drawings, and a recent autocad patch to an AECNETWORK.DBX file.  Between all three issues we where getting some terrible load times.  It was a struggle to eliminate the server, then eliminate the dref's and circular reference load issues, then when to blame CAD.

The problem looked like this.  Everyone has slow loading but can't pin point when it started.  It was a death by small paper cuts issue.  While the performance degraded slowly, it never was spotted because of poor drawing implementation and recent server issues.  After eliminating the first options we settled for the best time we could and started to accept 5 min load times.  We with lots of references and dref's, it is what it is.  Then along came a patch and we got the most difficult load times down to 1 min.  Totally acceptable.

Is there currently a way with the .net api to monitor the loading and regeneration times on drawings to that we can benchmark acceptable, and know when to blame a particular machine, the network, or the degradation of another acad dbx file?

I would imagine either an app that is standalone that can listen in on the loading of things, or a plugin that can log the loading and regeneration of objects and open.  This way we can pinpoint the particular xref, dref, and look for possible best practices.

Where would I start with a task like this.  My c++ and arx skills are near zero.

Thanks in advance,

Chris

[It's Alive!]

something like?

Start timer
AcEditorReactor::beginDwgOpen
AcEditorReactor::endDwgOpen
End timer

[nobody]

You won't believe the time and money we spent on analyzing this very problem with Civil 3d.  So many things affect its load time it's ridiculous. For those of us who use LDD in our office, this is the single item where C3D isn't as efficient as LDD was (or  from it's predecessor 20 years ago).  Autodesk has some bruises over this one, and it's evident every time they have to talk about lol.

That said, we found data references, since they act more like an attachment, rather than an overlay, play a big roll along with surfaces.  The less of both, the better load times (by several minutes).

[cb]

I was thinking more along the lines of monitoring the individual completion of internal processes.  Like the loading of dref's, xrefs, drawing database objects.  Then monitoring the processes during the 'regeneration' phase just before the drawing is ready.  This way if one or two xref's are causing 80% of the regeneration time and load time, we can look at those files.

It would be great to diagnose a slow dwg based on the pipenetwork regenerating being too slow or of if there is a slow down because its recursively dealing with loading of a pipe network that has been xref'd and also dref'ed.  I would imagine that you would see it load a few times in the logs. 

The more that can be monitored, the more we would know if the drawing had a poor structure, the network was slow that day, or a couple of minutes is just the best the file will load.  We have been beat up by so many issues lately that many users here feel like its totally normal to hit open and go to lunch during the 30 minutes it took to open or run purge.  It turns out it is not and autodesk had a patch for it but we have no way of knowing what is normal or out of wack without deep monitoring.  The software has become more complex and difficult to diagnose what's really to blame.

Of course serious network sniffing tools help I guess but it would seem a simple monitoring app of the loading mechanism in autocad would be ideal.  The more granular the better for shaping best cad practices and pointing the finger at needing network upgrades / user upgrades / machine upgrades / or nasty grams to vendors  .

[dgorsman]

I think you would be better off with an external utility to monitor system performance.  Check out Process Monitor (ProcMon): https://technet.microsoft.com/en-US/sysinternals/processmonitor.aspx.

[cb]

Check out Process Monitor (ProcMon): https://technet.microsoft.com/en-US/sysinternals/processmonitor.aspx.

This is definitely something to look into for the time being.  Is it possible to tap into what I see with the procman to real time log the behavior with dot net app? Isolate key processes running when the xref loads, possible tap into those with pinvoke or something to read which xref is loading and the time it takes.  Then chart duplicate xref's loading, duplicate dref's, load times, sync'ing, regenerating etc?

It can be time consuming to open a drawing and manual search each xref for dref's and other attached references.  I would like to log all of this when acad opens a file.

The other downside is that this requires deep understanding of procmon and admin rights.  I was thinking more of a utility that a user can run with autocad or outside with basic user privileges and then send a log when they have poor load times to evaluate against other load times.

Part of me feels like it can be done with arx, pinvoke, or some internals to transactions or reads.  Kind of like tapping into the reading of a file or image to use a standard completion meter widget with the ability to see what is loading and log the time.

[MSTG007]

We had an issue like that about a month ago with most of our currently made dwgs. It would take forever just to load. Save was quick and so was editing. What we saw as the issue was with Point Groups. In our template we have our own custom point groups. So as we were to insert blocks into other dwgs, it would create duplicate point groups. We had to delete all the other point groups. The other thing we had to do, was update our Civil3D 2016 SP2 to SP3. Were back to normal again. Hope that helps.

[BlackBox]

This was very helpful:

https://knowledge.autodesk.com/support/autocad-civil-3d/troubleshooting/caas/sfdcarticles/sfdcarticles/Civil-3D-Performance-degradation.html

Slowest load times for me, even after the above improvement, is loading any drawing with an XREF that has COGO Points (not empty Point Groups).

For large projects, I will export to acad just for those drawings, and there's a substantial reduction in drawing open time even as compared to small project drawings with COGO.

I originally did not use DREFs a lot in my sheets, for the purposes of Style management, but 2017 now has Style templates which helps with that... but not for Parts lists?

I still instead XREF my Pipe Networks and Profile Views, as I use Pipe Networks for Pressure mains as well as storm and sanitary, and DREF Null Structures don't come in correctly (with or without Labels). Even if they did, it's still less work to layout, label, and modify Pipe Networks in the same drawing (across and entire project), IMO.


Cheers

[cb]

This was very helpful:

https://knowledge.autodesk.com/support/autocad-civil-3d/troubleshooting/caas/sfdcarticles/sfdcarticles/Civil-3D-Performance-degradation.html

Cheers

Yes, this exact degradation issue was recently a big hickey for us.  We were pulling our hair out due to some inconsistencies with our file server, some poor drawing setups, and what seemed to be a wall in dwg open times.  What made it worse was that the fix noted was not released in a service pack for 2015.  While the performance fix was slipped into service packs for 2016 and 2017, not 2015.  We were able to patch our installs as noted in the fix but it was an eye opener that we should probably monitor for autocad degradation from the autocad side of things.

The patch improved our difficult open times of ~5-10 min to ~1-2 min.  That was a big deal to us.  Enough that I would really like to monitor open times for historical reasons and eliminate user issues from network to acad runtime issues.