On Wed, Dec 8, 2010 at 10:33 PM, Adrian Lienhard <[email protected]> wrote:
> Hi Martin, > > I took some application for which we use image segments to test Fuel > > - With Fuel serializing and writing to disk took 330s. File size is 16.1MB > - With image segments saving takes 4s and the file size is 2.4MB > but how are you using ImageSegment? just the primitive? because in order to compare it to Fuel, you should write all objects, including "outPointers". So you should use #writeForExportOn: or similar... funny it is only 4s in IS, since it has to do a #become, a full GC mark phase, etc... > > - When loading, I got a low space warning because the primitive > newMethod:header: failed. > - Loading with image segments takes 11 seconds > > I wonder what your rational is for "objects are much more times loaded than > stored". That's Fuel purpose. And it is useful for version systems, where you may commit once (a specfic version for example), but load hundred of times. > In our case its exactly the other way round. We store very often (like > every couple of minutes if there are changes), but only load when we restart > an image (this may be weeks). > > So I guess Fuel is not the best approach for you :) > HTH, > Adrian > > On Dec 8, 2010, at 17:50 , Martin Dias wrote: > > > Hi all > > > > Last months I and Tristan have been working on Fuel project, an object > > binary serialization tool. The idea is that objects are much more > > times loaded than stored, therefore it is worth to spend time while > > storing in order to have faster loading and user experience. We > > present an implementation of a pickle format that is based on > > clustering similar objects. > > > > There is a summary of the project below, but more complete information > > is available here: http://rmod.lille.inria.fr/web/pier/software/Fuel > > > > The implementation still needs a lot of work to be really useful, > > optimizations should be done, but we'll be glad to get feedback of the > > community. > > > > > > = Pickle format = > > > > The pickle format and the serialization algorithm main idea, is > > explained in this slides: > > > > http://www.slideshare.net/tinchodias/fuel-serialization-in-an-example > > > > > > = Current features = > > > > - Class shape changing (when a variable has been added, or removed, or > > its index changed) > > - Serialize most of the basic objects. > > - Serialize (almost) any CompiledMethod > > - Detection of global or class variables > > - Support for cyclic object graphs > > - Tests > > > > > > = Next steps = > > > > - Improve version checking. > > - Optimize performance. > > - Serialize more kinds of objects: > > -- Class with its complete description. > > -- Method contexts > > -- Active block closures > > -- Continuation > > - Some improvements for the user: > > -- pre and post actions to be executed. > > -- easily say 'this object is singleton'. > > - Partial loading of a stored graph. > > - Fast statistics/brief info extraction of a stored graph. > > - ConfigurationOfFuel. > > - Be able to deploy materialization behavior only (independent from > > the serialization behavior) > > > > > > = Download = > > > > In a Pharo 1.1 or 1.1.1 evaluate: > > > > Gofer new > > squeaksource: 'Fuel'; > > version: 'Fuel-MartinDias.74'; > > version: 'FuelBenchmarks-MartinDias.4'; > > load. > > > > > > = Benchmarks = > > > > You can run benchmarks executing this line (results in Transcript): > > > > FLBenchmarks newBasic run. > > > > > > Thank you! > > Martin Dias > > > > >
