From: Christopher S. M. <br...@ma...> - 2013-08-29 20:24:19
|
On Aug 29, 2013, at 10:38 AM, Tom Browder <tom...@gm...> wrote: On Thu, Aug 29, 2013 at 9:20 AM, Tom Browder <tom...@gm...> wrote: On Wed, Aug 28, 2013 at 10:49 AM, Christopher Sean Morrison <br...@ma...> wrote: On Aug 28, 2013, at 11:29 AM, tbr...@us... wrote: ... Note that it'll also be highly desirable to timestamp all objects (not just their attributes) ... and stash those timestamps as attributes. So this would imply we're even time-stamping our timestamps, which is of course ridiculous. It might be worth creating a timestamp struct (not in string form). That would reduce the memory footprint overhead substantially and let them be optional (null pointer implying unset). Looking at the draft db5 format manual it seems to me that adding a time stamp to an object is pretty straight forward (the easiest way is to add an attribute) Agreed. But it probably ought to be some kind of time struct (as you mentioned) on the object itself. I'll look into that instead of the attribute route. I think it'll be a noticeable performance difference if I wanted to show "recently changed" objects, for example. Scanning 10k strings vs 10k timestamps could be the difference between a 1ms realtime update and 100ms pauses in an interface (if done blocking of course). This is very similar problem to dealing with the region ID, los, material ID, and object color. In a modular fashion, I'm thinking a plugin module that would get registered describing how to encode and decode from an attribute (calling callback functions). Something VERY simple that would get called before export, after object import, and during attribute lookups. This would be so we don't end up with attributes and region ID fields being held in memory, needing to keep the two in sync. Now I see that that may be the route for attr stamping. Each attr has a unique index number (I think it's constant except when one is removed) that could be used as a key to identify its create and mod time stamps in the parent object's time struct. I'll also look into that. That attribute key could also be used as an index into another attribute object, a ledger of sorts that would hold the actual attribute timestamp data. There would be an issue of database concatenation (non-unique IDs), though, so I would probably still try to hijack the attribute format itself (and mod the db5 spec) to support binary attributes as a key=value field structure where the value is actually a data dictionary (not just a string). Cheers! Sean |