[Pharo-project] Xtreams?
Hi all, does anybody have any experience or opinion about the Xtreams framework? Haven't looked at it yet, saw it mentioned here http://www.cincomsmalltalk.com/userblogs/mls/blogView?showComments=true&prin... and it seems to have a Java impementation as well. Michael
There is an OMeta implementation for Squeak (http://www.cs.ucla.edu/~awarth/ometa/OMeta.sar). There are several PEG implementations on SqueakSource (http://www.squeaksource.com/AdvancedProgramming, http://www.squeaksource.com/PEG, ...). I've also written a Packrat parser framework (http://source.lukas-renggli.ch/petit), that I am using excessively as a tool for my research. It supports memoization (for speed) and left recursion (for convenience), though not as sophisticated as in OMeta. I've written a complete Smalltalk grammer, that produces the same AST as the parsers of the new compiler and refactoring browser do. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Mon, 12 Jan 2009 18:33:33 +0100 "Michael Rueger" <m.rueger@acm.org> wrote:
Hi all,
does anybody have any experience or opinion about the Xtreams framework? Haven't looked at it yet, saw it mentioned here http://www.cincomsmalltalk.com/userblogs/mls/blogView?showComments=true&prin...
and it seems to have a Java impementation as well.
I have not really used it, but a while ago I compared various serialization frameworks (BOSS, SRP, SIXX) in VisualWorks, see http://www.parcplace.net/list/vwnc-archive/0805/msg00186.html Michael Lucas-Smith then privately asked me to try and run the code with the then-current version of Xtreams. I had to (trivially) patch unmarshalling for Sets and then ran some tests comparing the three binary serializers BOSS, SRP, Xtreams. The numbers below each block are the results reported by printing the invocations four times in a row each. |td| ObjectMemory garbageCollect. td := TestData new. Time millisecondsToRun: [10000 timesRepeat: [ td saveToBytesBos ]] 8339 8387 8328 8631 |td| ObjectMemory garbageCollect. td := TestData new. Time millisecondsToRun: [10000 timesRepeat: [ td saveToBytesSrp ]] 1969 1995 1953 1958 |td| ObjectMemory garbageCollect. td := TestData new. Time millisecondsToRun: [10000 timesRepeat: [ td saveToBytesXtreams ]] 1113 1086 1089 1089 |td dump| ObjectMemory garbageCollect. td := TestData new. dump := TestData new saveToBytesBos. Time millisecondsToRun: [10000 timesRepeat: [ td loadFromBytesBos: dump ]] 2405 2465 2372 2491 |td dump| ObjectMemory garbageCollect. td := TestData new. dump := TestData new saveToBytesSrp. Time millisecondsToRun: [10000 timesRepeat: [ td loadFromBytesSrp: dump ]] 2228 2247 2278 2282 |td dump| ObjectMemory garbageCollect. td := TestData new. dump := TestData new saveToBytesXtreams. Time millisecondsToRun: [10000 timesRepeat: [ td loadFromBytesXtreams: dump ]] 1817 1845 1861 1838 HTH, s.
Never heard before. Is the VW package invoking the Java Xtreams package? Stefan do you have an idea why this would be so fast compared to the other approaches.
does anybody have any experience or opinion about the Xtreams framework? Haven't looked at it yet, saw it mentioned here http://www.cincomsmalltalk.com/userblogs/mls/blogView?showComments=true&prin...
and it seems to have a Java impementation as well.
I have not really used it, but a while ago I compared various serialization frameworks (BOSS, SRP, SIXX) in VisualWorks, see http://www.parcplace.net/list/vwnc-archive/0805/msg00186.html
Michael Lucas-Smith then privately asked me to try and run the code with the then-current version of Xtreams. I had to (trivially) patch unmarshalling for Sets and then ran some tests comparing the three binary serializers BOSS, SRP, Xtreams. The numbers below each block are the results reported by printing the invocations four times in a row each.
|td| ObjectMemory garbageCollect. td := TestData new. Time millisecondsToRun: [10000 timesRepeat: [ td saveToBytesBos ]] 8339 8387 8328 8631
|td| ObjectMemory garbageCollect. td := TestData new. Time millisecondsToRun: [10000 timesRepeat: [ td saveToBytesSrp ]] 1969 1995 1953 1958
|td| ObjectMemory garbageCollect. td := TestData new. Time millisecondsToRun: [10000 timesRepeat: [ td saveToBytesXtreams ]] 1113 1086 1089 1089
|td dump| ObjectMemory garbageCollect. td := TestData new. dump := TestData new saveToBytesBos. Time millisecondsToRun: [10000 timesRepeat: [ td loadFromBytesBos: dump ]] 2405 2465 2372 2491
|td dump| ObjectMemory garbageCollect. td := TestData new. dump := TestData new saveToBytesSrp. Time millisecondsToRun: [10000 timesRepeat: [ td loadFromBytesSrp: dump ]] 2228 2247 2278 2282
|td dump| ObjectMemory garbageCollect. td := TestData new. dump := TestData new saveToBytesXtreams. Time millisecondsToRun: [10000 timesRepeat: [ td loadFromBytesXtreams: dump ]] 1817 1845 1861 1838
HTH, s.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, 12 Jan 2009 20:40:02 +0100 Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Never heard before.
That's what I thought when I was told about StateReplicationProtocol (SRP), found on sourceforge, IIRC.
Is the VW package invoking the Java Xtreams package?
brrr... I don't think so, it might be two different implementation of an "Xtreams" idea, or just a random name clash.
Stefan do you have an idea why this would be so fast compared to the other approaches.
hmm... "if we can see farther today, it's because we're standing on the shoulders of giants"? I'd guess it's good design and good programming. s.
participants (4)
-
Lukas Renggli -
Michael Rueger -
Stefan Schmiedl -
Stéphane Ducasse