On 17 May 2011 15:51, <[email protected]> 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 < [email protected] > 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.
