On Sat, Dec 1, 2012 at 6:03 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

On 30 Nov 2012, at 23:39, Sven Van Caekenberghe <sven@stfx.eu> wrote:

> Hi,
>
> Based on feedback by Norbert Hartl, Stuart Herring and Dale Hendrichs (thank you) I improved the current STON version a bit.
>
> � � � http://ss3.gemstone.com/ss/STON
> � � � https://github.com/svenvc/ston
>
> Changelog:
>
> � � � A nasty cycle bug was fixed
> � � � Performance was improved, especially for large structures.
> � � � Some implementation changes (recursion done using a stack, stonProcessSubObjects: optimized using stonContainsSubObjects)
>
> I did some stress/performance testing/tuning. Using
>
> � � � STONTestMap classTreeExtended.
>
> to generate a structure mimicing the class hierarchy, with objects for all classes, about 7000 in my image and all methods, about 64000 in my image, with super/subclass and method owner links to create cycles. This results in a 7 Mb .ston file.
>
> The normal code, serializes this in 28 seconds and materializes it in 11.5 seconds.
> The 'fast' versions (using ZnBuffered[Write|Read]Streams and Fuel Large Datastructures) does it in 1.1 and 3.8 seconds respectively.

It occurred to me that I hadn't tried with Fuel (expecting it to be totally out of reach, since it is a binary protocol). Well, Fuel serializes my test structure in 5 seconds and materializes it in 1.2 seconds, the file being 6.4 Mb. Not bad for a textual protocol ;-)


So 5.6x for serializing and 9.5x for materializing. Similar stream result.
So, yes, not bad :) �SIXX �was way slower from what I remember.
Don't have time now but I will check your ��STONTestMap classTreeExtended �...
BTW, which stream class you use for the bench?
This does of course not proof a lot, results will depend on each specific use case.

> New users are always welcome.
>
> Sven
>
> --
> Sven Van Caekenberghe
> http://stfx.eu
> Smalltalk is the Red Pill
>
>
>





--
Mariano
http://marianopeck.wordpress.com