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. 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). Cheers, Max (Note: I don't read the users list so please put me on the CC explicitly if you want me to read on) > > Cheers, > > > Norbert > >> Cheers, >> >> >> On Tue, Jul 23, 2013 at 9:40 AM, Norbert Hartl <norb...@hartl.name> wrote: >> >> Am 23.07.2013 um 14:23 schrieb "jtuc...@objektfabrik.de" >> <jtuc...@objektfabrik.de>: >> >> > Norbert, >> > >> > Am 23.07.13 14:07, schrieb Norbert Hartl: >> >> Joachim, >> >> >> >> I'm aware that you can do serialization/deserialization yourself. I was >> >> asking for something to help along the way because a have quite some >> >> model classes to cover. I want a more generalized way of doing it. As >> >> often I really think about things _after_ I've sent the mail :) >> > >> > We seem to have a lot in common here. Regard it this way: sending the mail >> > made you think again. So the mail itself was all but useless. >> >> I think I have to options: >> >> >> >> 1. The most generic one is serializing into Fuel and compile the >> >> ByteArray in a method. >> >> 2. The most readable one will be using STON and compiling the STON string >> >> into a method >> >> >> >> Maybe I should try both. >> > I'd be very interested in what you find. I guess Fuel is smaller and maybe >> > even faster. STON, OTOH, is much friendlier for comparing versions and >> > such. >> > >> Well, I can't look at the method but I don't find ByteArrays not that >> interesting anyway. So the actual size of the serialized byte array is >> >> (ByteArray streamContents: [:stream| >> FLSerializer serialize: TCAP current model on: stream ]) size >> >> is 237445 Bytes. Serializing >> >> [ MAPExampleModels class compile: 'tcap >> ^ ', (ByteArray streamContents: [:stream| >> FLSerializer serialize: TCAP current model on: stream ]) >> storeString ] timeToRun >> >> took 647 ms >> >> but >> >> [FLMaterializer materializeFromByteArray: MAPExampleModels tcap] timeToRun >> >> took only 30ms. Basically I'm not fond of putting too much binary stuff into >> compiled methods but it is the most easy and reliable way of providing tests >> with test data. The whole grammar is stored in methods as well. It is text >> but…. >> >> I think I stay with it for a while. >> >> Norbert >> >> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com > > > > > -- > Mariano > http://marianopeck.wordpress.com
