<br><br><div class="gmail_quote">On Wed, May 25, 2011 at 2:18 PM, Sebastian Sastre <span dir="ltr"><<a href="mailto:sebastian@flowingconcept.com">sebastian@flowingconcept.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word">Sounds awesome!<div><br></div><div>The streaming feature is appealing.</div><div><br></div></div></blockquote><div><br>Yes. At the beginning we were using MultiByteFileStream directly. Then we use a ByteArray new writeStream as a full buffer of the full graphs.<br>
We used a lot of memory but speed was very good. But it was also not good because the array was growing all the time.<br>So, Sven suggested a ZnBufferedWriteStream he was using for Zinc. That way, we have a buffered write stream were we can set a buffer, say 5000 elements, and the speed is almost the same as using a full baffer, because ok, we go a little more to disk but on the other hand the collection buffer doesn't need to grow.<br>
<br>So....in conclusion, when using a buffered stream writer instead of MultiByteFileStream we increased speed about 12x and with a little buffer of 5000 elements.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div style="word-wrap: break-word;"><div></div><div>I might take a look at it. Won't hurt as a redundant repo backup tactic</div><div><br></div></div></blockquote><div><br>:)<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div style="word-wrap: break-word;"><div></div><div><div><div><div><div><a href="http://twitter.com/#%21/sebastianconcpt" target="_blank">sebastian</a> </div></div><div><br></div><div>o/ </div></div></div></div><div><br></div>
<div><br></div><div><br><div><div><div></div><div class="h5"><div>On May 24, 2011, at 5:39 PM, Martin Dias wrote:</div><br></div></div><blockquote type="cite"><div><div></div><div class="h5">Hi folks. I am really happy to announce that ESUG is sponsoring me for Fuel development through the ESUG SummerTalk. I am Martin Dias, a student at Buenos Aires, Argentina. The idea behind this SummerTalk is to implement Fuel, a binary, fast and general-purpose object graph serializer in <a href="http://www.pharo-project.org/" target="_blank">Pharo</a>. It is based on VisualWorks' Parcels ideas.<br>
<div class="gmail_quote">
<br>Actually, the project has already started since several months. Tristan Bourgois and I started with the project while doing an internship with <a href="http://rmod.lille.inria.fr/web/pier" target="_blank">RMoD, INRIA</a>. Since a couple of months, <a href="http://marianopeck.wordpress.com/" target="_blank">Mariano Martinez Peck</a> joined the team, and now he is the official mentor in the SummerTalk.<br>
<br>ESUG website for SummertTalk: <a href="http://www.esug.org/wiki/pier/Promotion/SummerTalk/SummerTalk2011" target="_blank">http://www.esug.org/wiki/pier/Promotion/SummerTalk/SummerTalk2011</a><br><br>The website with all the necessary information is here: <a href="http://rmod.lille.inria.fr/web/pier/software/Fuel" target="_blank">http://rmod.lille.inria.fr/web/pier/software/Fuel</a><br>
It even includes slides explaining the algorithm. In addition, a paper is in progress.<br><br>For the moment, Fuel already provides the following features:<br><br>- Fast pickle format. It is much faster to materialize than to serialize.<br>
- Correctly support class reshape (when the class of serialized objects has changed).<br>- Serialize ANY kind of object. For the moment there is no
object to our knowledge that we cannot serialize and materialize.<br>- Be able to completely serialize classes and traits (not just a global name).<br>- Support cycles and avoid duplicates in the graph.<br>
- Integration to <a href="http://www.moosetechnology.org/" target="_blank">Moose</a> with an extension to export and import their models.<br>- Detection of globals: for example if you serialize Transcript, it is not duplicated and instead managed as a global reference.<br>
- Solve common problems like Set rehash.<br>- Buffered writing: we use a buffered write stream for the serialization part (thanks Sven!).<br>
- No need of special support from the VM.<br>- Try to have a good object oriented design.<br>- Well tested (about 120 tests, for the moment).<br>- Large set of benchmarks (even benchmarks for Moose extension).<br><br>And of course, there are a lot features for the future. You can see some of them in the website and some in the issue tracker: <a href="http://code.google.com/p/fuel/issues/list" target="_blank">http://code.google.com/p/fuel/issues/list</a><br>
<br>We really appreciate all kind of feedback and comments. If you want to try it, check in the website how to do it. It is extremely easy. <br><br>Once again, I want to thank a lot to ESUG for sponsoring the project. I plan to create a "news" section in the website with some RSS. I will keep you informed.<br>
<br>Best regards,<br>Martin<br>
</div><br></div></div><div class="im">
_______________________________________________<br>seaside mailing list<br><a href="mailto:seaside@lists.squeakfoundation.org" target="_blank">seaside@lists.squeakfoundation.org</a><br><a href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside" target="_blank">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a><br>
</div></blockquote></div><br></div></div><br>_______________________________________________<br>
seaside mailing list<br>
<a href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside" target="_blank">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br><br>