On Jul 23, 2013, at 5:33 , Norbert Hartl <norb...@hartl.name> wrote:
> Max, > > Am 23.07.2013 um 17:27 schrieb Max Leske <maxle...@gmail.com>: > >> >> On 23.07.2013, at 15:32, Mariano Martinez Peck <marianop...@gmail.com> wrote: >> >>> >>> >>> >>> On Tue, Jul 23, 2013 at 9:48 AM, Norbert Hartl <norb...@hartl.name> wrote: >>> Mariano, >>> >>> Am 23.07.2013 um 14:43 schrieb Mariano Martinez Peck >>> <marianop...@gmail.com>: >>> >>>> Norbert, does the model have lots of strings? Because if so you can try >>>> using the compression. It may increase speed. There is always a trade off >>>> between the additional time of compressing/uncompressing. But if the model >>>> has quite an amount of strings, since writing to disk is also slow and the >>>> final stream would be smaller, it could be faster. >>>> >>> thanks. Yes, the model is a lot of Dictionaries having string keys. And >>> there are lots more. The usage of the model is write once read many. And >>> 30ms is good enough for me. So I might try compression only to see the >>> difference. Well, and maybe to reduce storage size. The mcz is now 261 kb. >>> >>> Thanks, I'll see but I am already satisfied with the current approach. >>> >>> >>> Mmmm I thought it was ready, sorry my bad. Seems it was not ready nor >>> integrated: https://code.google.com/p/fuel/issues/detail?id=160 >>> But I might be wrong. >>> Max? >> >> No, that issue is still open. You're welcome to use the experimental version >> though (Fuel-MaxLeske.757.mcz in >> http://www.squeaksource.com/FuelExperiments) but keep in mind that this is a >> few months behind stable. >> > I'm not sure the priority is high enough to try. > >> The other idea however, that Mariano describes in the linked issue, is >> available but probably not desirable: simply pass a compressing stream to >> Fuel (see FLGZippedBasicSerializationTest for an example on how to do that). >> That will compress *all* data, not only strings (which is the idea outlined >> in the linked issue). >> > I don't think that will gain anything. A monticello package is written as > zip. So I wouldn't expect much from an additional compression. > > thanks, > > Norbert Unless MAPExampleModels tcap is something like ^'mySerializedTCAP.bin' asFile readStream binary contents instead of tcap ^#( 0 0 0 … ), compressing the fuel binary output would save you some runtime memory (method literal size) / .changes space (method source), though for test resources I guess that's a less relevant aspect than for other resources. Cheers, Henry
