On Sat, Dec 1, 2012 at 6:03 PM, Sven Van Caekenberghe <[email protected]> wrote:
> > On 30 Nov 2012, at 23:39, Sven Van Caekenberghe <[email protected]> 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
