On 17 May 2011 15:51, <csrabak@bol.com.br> wrote:
Mariano,
It is early in the morning right here and I might have read too hastily to your post, but from the diagonal reading I gave it seems you're going quickly to reinvent the wheel!
Those issues you rise are typical of database (engine) programming. Â Also, IIRC Smalltalk has another approach to persistence of objects called BOSS, have you given a look at it and check if a mix of Fuel + BOSS would accomplish your intent?
I think its implemented from scratch for one big reason: devil is always in details. Object format, streams, protocol and dozen of various things may differ from one smalltalk dialect to another one. Also, i assume most of us are never heard about BOSS. Just googled it and found couple citations which related to VW world, but not to Squeak/Pharo. Is it runs on Pharo? What its license? But by saying that, i'm a of course in favor of having more and more cross-dialect solutions.
-- Cesar Rabak
Em 17/05/2011 10:21, Mariano Martinez Peck < marianopeck@gmail.com > escreveu: Hi guys. Together with Martin we are developing a fast object graph serializer called Fuel. The idea is to use a pickle format similar to VW Parcels. Right now we are able to correctly serialize (almost) all kind of objects (from different classes and so on). The algorithm is working quite well and we are already quite fast. We also know how to encode more or less efficient some of the "primitive" classes like Floats, SmallIntegers, ByteString, ByteArray, etc, etc.
What we really don't know anything about streams. For example, until now, we were using just a MultiByteFileStream and doing all the time things like #next:Â #nextPutAll:Â #nextWordPut: etc...
Now Igor told us for example, to use a buffer like this:
 | bufferStream |  bufferStream := ByteArray new writeStream.
 (FLSerializer on: bufferStream)  serialize: anArrayToSerialize.
 aFileStream nextPutAll: bufferStream contents.
and that it at least 2 times faster than we were doing.... I guess it is because it goes to the disk only once. But MultiByteFileStream uses a buffer, doesn't it ?
For reading (deserialization) we are not doing nothing special. We just open the file stream and we read with #next #nextString ... etc.
Another thing is which kind of file stream should we use. MultiByteFileStream ? StandardFileStream ?
So...before spending time in some optimizations, are there "known" things that we should check?
Thanks in advance,
-- Mariano http://marianopeck.wordpress.com
-- Best regards, Igor Stasenko AKA sig.