© 2011 Autodesk Managing Your AutoCAD®/RealDWG® Model Memory Footprint for Better Performance Bill Adkison MarinCAD Software Engineering CP4286-U November 29, 2011

© 2011 Autodesk Unconference Topic Suggestions  Topics You All have in Mind  Fragmentation  Large 3d models  Managing dependencies .NET vs. ARX/Native vs LISP  Topics Bill has in Mind  The End of the 32-bit Era (almost)  DWG Database Memory Overhead  Differing Memory Characteristics of different AutoCAD Visual Styles  Use of AcDbDatabase::reclaimMemoryFromErasedObjects(AcDbObjectIdArray)  The Advantages and Disadvantages of Disabling UNDO recording  XData versus AcDbObject::extensionDictionary  One-Shot allocation of Huge Arrays

© 2011 Autodesk Fragmentation, Large Models  32-bit OS: 2Gb or 3Gb limit is the real ceiling, but ragmentation within that space in the process will slow down performance before the final limit  Even on 64-bit systems, ACAD going over ~6Mb starts slowing down a lot  Large Models:  PartialOpen with index structures is a good way to filter DWG content and memory  Use INDEXCTL to create spatial and layer index structures  Partition DWGs into Xrefs with Demand Loading  XREF Clipping (XCLIP)

© 2011 Autodesk.NET vs Native ARX vs LISP .NET is usually not a memory hog, unless you open a lot of objects simultaneously  LISP is a LOT of overhead, but can be useful anyway for prototyping.  VLX (building a compiled LISP app) is a good way to eliminate a lot of overhead

© 2011 Autodesk End of 32-Bit PC Era (almost)  Migrating to x64 is good short term, and long term solution  32-bit apps on x64 OS can save some memory, some performance cost  AutoCAD doesn’t support x86 on x64OS, but it can be done with registry hacks ( me for details, I have to learn them for a client anyway).

© 2011 Autodesk AcDbDatabase Object consumption  Big DWGs commonly have:  ~10^4 - 10^6 entities (i.e. 99% of the memory)  ~10^3 – 10^5 Symbol Table Records and XDict entries (still big, but not the typical problem)  Overhead of:  bytes per handle/ObjectId + GS Spatial Index  bytes per Entity Common Fields  >1Mb bytes per Entity

© 2011 Autodesk Different AutoCAD Visual Styles  2D or not 2D, That Really is the Main Question  All non-2DWireframe modes have a common 3d GS  2D is good for:  Model graphs with unshared nodes and static 3D viewing.  Legacy appearance (relatively uncommon, but significant)  Session with heavy document locking processing (3D Gs triggers often)  Others are good for:  Model Graphs with shared and/or dynamic 3D viewing  Advanced rendering modes  Mem Diff: SharedNodeDwg (1024 refs to 1 block): 2D – 1.2Gb == 3D

© 2011 Autodesk AcDbDatabase::reclaimMemoryFromErasedObjects  Intended for scenarios repeatedly adding/erasing entities.  ~16 bytes residual per entity, out of 200b – 2Mb per entity  Slightly better with UNDO disabled, but not much

© 2011 Autodesk Disabling UNDO/REDO  Very Safe by Command Line  Not Very Effective for “common” operations with efficient UNDO recording  Very Dangerous by API  Disabling for specific database ops Must be self-contained

© 2011 Autodesk XDATA vs extensionDictionary/XRECORD  XDATA has lower overhead, about 48 bytes, plus 32 bytes per RegApp section, then very efficient. But a 16Kb limit for XDATA per object, and you need to share with other apps.  extensionDictionary is about 100 bytes of overhead, plus 100 bytes per added object. But after that, there are no capacity limits other than file size and memory size.

© 2011 Autodesk Autodesk, AutoCAD* [*if/when mentioned in the pertinent material, followed by an alphabetical list of all other trademarks mentioned in the material] are registered trademarks or trademarks of Autodesk, Inc., and/or its subsidiaries and/or affiliates in the USA and/or other countries. All other brand names, product names, or trademarks belong to their respective holders. Autodesk reserves the right to alter product and services offerings, and specifications and pricing at any time without notice, and is not responsible for typographical or graphical errors that may appear in this document. © 2011 Autodesk, Inc. All rights reserved.