Last fall, I started to receive a lot of calls from end users who were reporting that AutoCAD (various flavors) was acting sluggishly. From looking over their shoulders, I could tell that it wasn't just their imagination. In particular, executing copyclip caused the progress meter on the status bar to show that something was processing and it took several seconds before the user was able to paste. At this point, sometimes the paste worked, and other times it did not.
Feeling confident in our hardware and software configuration, I started to examine the DWG files themselves, looking for anything out of the ordinary - dense hatch patterns, entities miles away from the project - the usual suspects. As I weeded out groups of entities at a time looking for the culprit, I ended up with a completely empty drawing file that was still 7+ megabytes after a complete purge.
Upon closer examination, there were still thousands of unpurgable linetypes left behind in the drawing file as shown below.
It seems that, other than the names, many of these linetypes were duplicates. After a little more digging, I discovered that these linetypes were all tied to the data dictionary called acad_dgnlinestylecomp. This would seem to indicate that they came from a Microstation DGN file at some point in time. While we do have some Microstation users, they don't share files with the department who first started reporting this problem to me. Furthermore, the linetype/linestyle names were all unrecognizable to everyone in out office. This suggests that that they came from somewhere else.
I quickly wrote a small command to eradicate the acad_dgnlinestylecomp dictionary from affected DWG files, and when run, performance was restored to expected levels for all of the end users who experienced this. Unfortunately, it seemed like the problem kept reappearing in the same DWG files.
It was then that I started experimenting a little more with these linetypes and I discovered that they're extremely contagious from one DWG file to the next. If a user copies
any entity from a DWG that contains these linetypes into an otherwise clean DWG file, then the destination drawing inherits all of the excessive linetypes, regardless of the source entity's linetype, and regardless of whether or not a DGN file was ever imported directly into the problematic DWG file itself.
It was then that I realized that we had another compounding problem on our hands. If you've been using AutoCAD (or AutoCAD based verticals) for years, you might remember that named layer filters were just as contagious back in the 2000i / 2002 era. More recently, scale lists were contagious from one DWG file to the next circa 2008. As with the previous contagious bloat, it seems that if I have one DWG file with 1000 uniquely named DGN linestyle names, and I copy an entity from it into another DWG file with 2000 uniquely named DGN linestyle names, then I end up with 3000 unpurgable linetypes. If I then get a polluted DWG file from an outside source and it contains another 5000 linestyles, and I happen to copy a single entity from it into my previously polluted DWG file, then I have 8000 linetypes, and so on.
Upon further examination, I determined that this problem has been going on for far longer than I've known about it. It's likely that when it was just a few dozen linetypes per DWG file, the performance hit wasn't noticeable. It wasn't until the problem started to snowball that it was brought to my attention.
I wrote a trigger into my company-wide acaddoc.lsp file that identifies the problem when anyone opens a drawing file and encourages end users to cleanse their DWG file. This process is very reactive, though, and Autodesk should make an effort to make these linetypes less contagious, or at least purgable using the built in purge command. As of AutoCAD 2014, though, we're still fighting the problem.
I've noticed that DWG files that are received from other firms are similarly polluted with excessive unpurgable linetypes and I have to wonder how they're handling it. I would hope that nobody has gone as far as to buy new hardware to address the problem, but that possibility does exist. After all, when it was initially reported to me, it was with the usual request of, "I need you to get me a new computer, watch how slow mine is."
Below is a sample of the code that I use to remove all DGN linestyles from the drawing. Be advised, though, that it is brute force and it will remove the linetype even if it's used. If one or more linetypes are used, then the linework doesn't get erased. Rather, the used DGN based linetypes retain their name and revert to the appearance of continuous. In our case, we never used the DGN linetypes anyway so I consider it to be fairly safe for us.
If you do use this code, please be aware that there is no warranty of any kind and I strongly suggest that you make a backup of you DWG file before you run it.
(defun c:cleandgnbloat (/)
(if (dictremove (namedobjdict) "acad_dgnlinestylecomp")
(progn
(princ
"\nClean DGN bloat complete. Please check your file for any errors. A purge is recommended."
)
)
(princ
"\nacad_dgnlinestylecomp not found. This file will not benefit from cleandgnbloat."
)
)
(princ)
)
Kean Walmsley has been kind enough to share a more elegant solution with the community
on his blog. If you use Kean's solution, then to stay ahead of the problem, you might want to identify the problem in your files by using something like this in your acaddoc.lsp:
(if (dictsearch (namedobjdict) "acad_dgnlinestylecomp")
(call kean's command here)
)
Edit: If you'd like to test this behavior for yourself, check out
this file. Merely copy the polyline out of it into a new blank DWG and then save the new file. Notice how the new file contains almost 4 megabytes of unpurgeable linetype definitions. Please be very careful with this file, though. I wouldn't want it to begin to pollute your files.
