On Fri, Jan 22, 2010 at 12:35 PM, Stéphane Ducasse < [email protected]> wrote:
> hi guys > > the more I read about imageSegments the more I would like to remove them > (or to package them > carefully - not sure that this is possible) and may be add a new class to > just have one simple way of invoking the save (but not swapping back in) > > I think that mariano diving into them is a great phd exercise but on the > long run > I see it as a brittle mechanism. > > what do you think? > David Leibs' work on parcels in VW demonstrated that high-performance packaging can be done with no VM support. When you implement a binary format, carefully designed for unpacking performance, at the image level you get the freedom to add flexibility. I added shape change support to parcels (and some higher level features that aren't relevant here) after David had left. So I think the right approach is to reimplement image segments entirely in the image without special VM support and add metadata to the format (class shape information) and you'll probably end up with something that is nearly as performant but much more flexible and evolvable. The two keys to the performance of David's design are the separation of objects from their references and the btching of object allocations. A parcel file starts with a number of allocations of well-known classes (e.g. this parcel contains 17 large integers of the following sizes, and 3 floats, and 17 symbols of the following sizes etc) followed by an arbitrary number of "N instances of class X". So the unpacker populates an object table with indices from 1 to N where N is the number of objects in the parcel, but it does so in batch, spinning in a loop creating N instances of each class in turn, instead of determining which object to create as it walks a (flattened) input graph. After the instance data comes the reference data, which slots refer to which objects. Again the unpacker can spin filling in slots from the reference data instead of determining whether to instantiate an object or dereference an object id as it walks the input graph. So loading is much faster than e.g. ReferenceStream-style approaches. 2¢ best Eliot > Stef > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
