What's going to slow down the performance of a drawing more:
- A ****-load of Lines, Arcs, Circles
- A ****-load of Text, Mtext
- A ****-load of Dimensions and Leaders
In my experience, it's a toss-up between #2 and #3, but the variable is the font type being used: standard or TrueType®. The fancier the font styling the more overhead incurred as well. At least try to put the italicized scrolled Gothic serif text on a separate layer and freeze it before saving and closing, so it doesn't grow a beard on the next person waiting to open it.
When inserting other DWG content, if you don't explode the insertions, be sure that someone has taken the time to open the original DWG and cleaned it up. If you do explode them, be sure to run at least two PURGE operations afterwards. It might also help to run AUDIT and fix any corrupt garbage as well. Don't forget that there's still a lot of DWG content being reused from R12 days.
One more thing about DWG libraries: If you're still inserting crap from 2002, 2003, or even from back in the 1980's or 1990's, take a day or two and do NOTHING else but open, clean up, and save those in the current version. Past versions of RECOVER, PURGE and AUDIT are known to have missed a lot of corrupted or incomplete drawing data for which the newer versions can easily detect and repair. Why repeat the same break-fix cycle for every subsequent reuse when you can "fix" it once and be done with it?
Layers
Layers. Do you REALLY need to max out the number of layers in your drawing? Ask yourself if there's a reason besides someone thinking it would be "logical" to put every thread on every bolt onto its own unique layer, separate from the bolt and the bolt head as well. I mean: Really?
And while I'm on the subject of layers: It's always nice to use descriptive layer names like "borders" or "interior walls", rather than the 1980's method of "1", "2" and "3", but let's not go overboard? Layers like "Interior walls with blue paint and red trimming for guest rooms only" is kind of stupid, and yes, it does add a bit of drag on performance, especially when you have 254 others with equally verbose names.
While this is technically not a performance issue, the use of long filenames is quite often reason to have someone beaten with a coffee pot. I've seen names like "Door bracket for main machinery space on the northeast side of the upper level - part 4, stage 3.dwg". The person that chose to use that name should be dunked in a tank of sulfuric acid, then their skeletal remains should be mounted at the front door entrance as a warning to others not to behave stupidly. Oh, and if they use this same pea-sized brain thinking when naming folders and nested folders, maxing out the Windows string limit, it's time to hang a douche bottle on a string around the neck bone of that skeleton.
Saving Backward Versions
We've all had to save back to an earlier format in order to help out our customers who can't afford to upgrade. Quite often I've seen people set the default SaveAs option to that earlier release, making the default process one that converts on every save and also has to convert on every open as well. Don't do it! Repeatedly converting drawings like that, especially large drawings, is asking for trouble and adds a ton of overhead for no real benefit. Keep your drawings in the current format. When it comes time to send deliverables in earlier formats, do the conversion at that point only. You will eliminate performance drags as well as reducing the potential for corrupting drawing data or crashing the application (aka "fatal error / unhandled exception" events).
One more thing: Don't overwrite the production drawing with the conversion to the earlier format! Place the converted files in their own folder. When it comes time to reopen the drawing and make additional changes (or insert it into yet another drawing), use the current format file, and do another conversion only when necessary.
If you're nodding at any of this, chances are you've encountered it before. If you're upset by any of this, chances are you are a major part of the problem.
0 comments:
Post a Comment