By this response I gather that you have minimal experience in manipulating AutoCAD entities in general (no offence).
None taken, I've don't!
I think the trouble here is I'm trying to do something autocad entities weren't designed for. I wonder if I explain the problem a little better perhaps you could recommend the best way forward.
I need to attach a lot of named data fields (hundreds, maybe over a thousand per object) to a lot of objects (tens of thousands) in an autocad drawing. So efficiency of reading, writing and storing data matters somewhat. Not all objects will contain all data fields (indeed some will not contain any).
Currently I do this using xdata. I attach a huge list of xdata to any object, registered to my app, in alternating pairs of name and data. So on one polyline I might have 2.0 fish, 3.5 eggs:
(1000 .
"fish") (1040 .
2.0) (1000 .
"eggs") (1040 .
3.5) ...
(and . loads
) (more . pairs
) (of . dotted
) (pairs . with
) (strings .
and) (float . values
)
while on another I might have 3.14 eggs and 7 hams:
(1000 .
"eggs") (1040 .
3.14) (1000 .
"hams") (1040 .
3.5) ...
(and . loads
) (more . pairs
) (of . dotted
) (pairs . with
) (strings .
and) (float . values
)
This xdata technique is inefficient in two ways. First, I store those strings many times over. This is simple to solve, I'm going to replace the strings with integers and attach a string->integer lookup dictionary to the main document. Fine.
Second, retrieving one piece of custom data from an object takes O(n) time where n is the average number of bits of data I've attached to each entity. It would be nicer if I could attach a dictionary of string->data (well, int->data if I do what I just said with the strings) to each object thereby reducing lookup time to O(log n). (Not an array as not all objects carry all the data).
If I understand what you're saying though this will carry huge overhead, as dictionaries cannot hold raw floats and have to hold entities. Thus the storage overhead for keeping the data in a per-object dictionary will be large - all the extra entity gubbins I complained about will have to accompany every single float I put in a dictionary.
So what do you reckon? Should I just stick to xdata and bite my tongue about the linear access time?
Or maybe I should hold all this extra data in a document level dictionary which does lookup from string -> [a long list of entity/float pairs] (albeit at the cost of losing direct spatial indexing for the data via it's linkage to entities). In which case you can see why I'd need to know where my own data starts in the Xrecord entity, because with a long list of
(105 .
"7ff26e8") (40 .
2.0) (105 .
"7ff253b") (40 .
3.5) ...
(and . loads
) (more . pairs
) (of . dotted
) (pairs . with
) (entitynames .
and) (float . values
)
I can't use assoc to retrieve my own data (or maybe I can - please tell me I'm wrong!).
Thanks for reading this far, I'd be interested to know what you think