Upload
cathleen-whitehead
View
217
Download
0
Embed Size (px)
Citation preview
© 2011 Autodesk
Managing Your AutoCAD®/RealDWG® Model Memory Footprint for Better PerformanceBill AdkisonMarinCAD 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 (email 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: 16 - 32 bytes per handle/ObjectId + GS Spatial Index 96 - 128 bytes per Entity Common Fields 200 - >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.