Transcript AcDbDatabase::reclaimMemoryFromErasedObjects

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 (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:





Others are 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)
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.
© 2011 Autodesk