Ken Taylor wrote: > Peter Amstutz wrote: > >> 1. Memory footprint >> >> The current s4 design has a lot of per-vobject overhead, leading to a >> significant memory footprint. The development version improves on this >> a bit, but the honest truth is that the implementation was not written >> with memory efficiency in mind. The s5 design will attempt to address >> in various ways, including attempting to directly minimize the byte >> count of crucial classes and data structures, and by using the >> "flyweight" pattern to collapse identical classes into a single shared >> instance. >> >> In particular, symbols (method names, message fields, types, etc) will >> be stored in a single global symbol table. This will ensure that such >> strings (which are expected to be used a lot in the system) are not >> duplicated, and has the convient effect of also making string comparison >> a constant-time pointer comparison instead of a linear time compare. > > This seems like a very good optimization, given how string-heavy the system > is. Could string tables also be used to compress COD files more? How about > network optimization by having two sites "share" a string table (or have a > static standard string table of commonly used strings in the "core" > protocol?). Also ... are properties stored as strings at the moment or as > native bytes (I actually don't know this)? If they're stored as strings, > compressing them to native data structures would probably be a big win too > (same thing goes for properties with storing them in COD and sending them > over the network). > > [I also had another idea related to network optimization -- which is > unrelated to memory footprint. The idea is particularly for large worlds > with lots of objects to listen to: instead of listening update messages > sending the whole message string and object identification, etc, have an > "optimized listen" protocol, where a chosen-at-runtime "tag" is used to > identify a certain kind of update message coming from a specific object, and > that's all you need to have in the network traffic (other than the actual > updated values, of course). This could even be done transparently at the > network interface level] > >> Another method for making the most out of the memory will be the ability >> to load vobjects from persistant storage on demand, and swap out rarely >> used vobjects. This will allow a site to contain many more vobjects >> than would otherwise fit in RAM. This > > Could this also be extended to support persistant transparent caching of > remote sites that have been visited? Perhaps paired with a new method to > query certain information about vobjects, such as is-cacheable and > last-updated/version? > >> To reduce the footprint of vobjects themselves, I am introduce a concept >> called "embedded children". These are objects that appear in protocol >> terms to be independently addressable vobjects that can send and receive >> messages, but are actually stored as a field of another vobject. This >> emerged from the observation that while it was extremely powerful from a >> design pattern standpoint for properties to be first-class vobjects, in >> s4 this often led to situations where it hundreds of bytes of overhead >> to store even a single four byte integer (for example). As an embedded >> child, the child vobject is simply a normal data field in the parent >> class, and it falls upon the parent sends and receives messages on >> behalf of the child. > > Sounds reasonable... What reasons (other than asthetics/symmetry) are there > for properties to be first-class? Will a property object ever have children? > Will one ever be at site root with no other parent? Will one ever be a > meta-object other than "property"? I guess you could have two parents > sharing the same property if it's a big one ...
Heh, well actually we tried that :) In s2 properties were indelible components of their parent objects. But it made everything more complicated and made the properties themselves much less useful. Being able to share properties is a critical feature of VOS that has emerged. And all the usefulness that comes from metaobjects/vobjects too-- Pete mentioned FileProperty and ExtrapolatedProperty (which no longer exist), but the new vostoolbox library I've been working on recently has several property subclasses; since they're metabobjects you can instantiate them remotely (e.g. in mesh, "create foo property:property.foo" With s5's new "embedded" children, you will still be able to optionally override an embedded child with a full Vobject. > Yes. I've run into this "ls at site root" problem and it's a bit annoying :) > And orphaned vobjects just seem like a lose. Related to this, I added a new setting and command to mesh, "cache". The setting does an initial request for all objects when you enter a new object to cache them. This doesn't actually solve the problem (since you still have to wait for the initial cache) but it makes the actual "ls" command operate at a reasonable speed. Set settings in mesh with the "set" command (and you can put this command or any other commands in ~/.mesh/meshrc). Reed _______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
