On Jan 22, 2010, at 9:59 PM, Eliot Miranda wrote: > > > 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.
Thanks I read a lot the parcel paper roel wrote about the pickle format. I reviewed it several times. I'm found of the idea that you can spend time saving if you get really fast loading :) But the paper was never crystal clear to me and I was always sad about that. I remember the first time I loaded RB with the parcels (20 min vs a couple of seconds). > > 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. Ok I see the idea. > > 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
