Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Mariano Martinez Peck <marianopeck-Re5JQEeQqe8AvxtiuMwx3w <at> public.gmane.org>
Subject: Fuel vs. StOMP (answer to blog post of Runar Jordahl)
Newsgroups: gmane.comp.lang.smalltalk.pharo.devel
Date: Wednesday 13th July 2011 08:56:51 UTC (over 6 years ago)
Hi guys. Several people asked several times the differences between the two
"new" serializers Fuel and StOMP. Runar wrote several blog posts about it:

http://blog.epigent.com/2011/07/new-smalltalk-object-serializers-fuel.html
http://blog.epigent.com/2011/07/comparing-speed-of-stomp-and-fuel.html
http://blog.epigent.com/2011/07/fuel-and-stomp-best-of-both.html

So I would like to give you my point of view as a Fuel developer. Which are
the main differences between Fuel and StOMP?

1) Portability. What that means?   "portability" is too wide to just talk
without details. For me, portability in this case means two things:
portable
format and portable code.
Portable format:  In a dialect/language XXX be able to materialize a 
stream
which was serialized in a dialect/language YYY.
Portable code: That the code of the serializer can also work in another
dialect/language (not necessary including portable format).

Fuel will does not do focus in portable format. At least, we will not do
extra effort to support that. Regarding portable code, it is not Fuel first
goal to be portable to other dialects but it is not that difficult anyway.
In fact, Fuel has been even ported to Newspeak. In the contrary to Fuel,
StOMP wants to be portable in both ways, format and code. But of course, it
is difficult to find portable representation of certain objects like
BlockClosure, MethodContext, Class, Trait, etc. StOMP do not deal which
such
objects due to the lack of those portable representations. In Fuel, we can
serialize those objects but not in a portable way.

So...next differences are:

2) In Fuel we want to be able to correctly serialize *any* kind of object.

3) Fuel will try to get the fastest way to serialize or materialize an
object. StOMP will use the most fastest available while trying to generate
a
portable representation.

4) Another important difference is that Fuel is faster in materialization
and StOMP in serialization. Why? Because a tool build on top of Fuel will
be
used for code management and loading is done much more times than saving
(think as in parcels). Notice that this doesn't mean we are slow in
serialization. We are faster than most of the serializers, but not as much
as StOMP.
What are the reasons of the differences in performance?  because of their
design and internals. It is a trade-off. To be faster at materialization,
we
do some extra work in serialization. StOMP does not do extra optimization
for materialization and hence serialization is faster.

What is that "extra" we do?  Ok, we have wrote a whole paper for IWST 2011
so I won't repeat myself. I will let you know when we get the notifications
of the paper so that we can make it public.

Regarding your excellent paragraph: "But... A partial solution would be to
use an intermediate format for *serialization*. This format would support
fast serialization, and therefore be similar to StOMP's format.
The intermediate format would for example be used when a user needs to
quickly commit changes to a database. Later, the intermediate format could
be transformed to a format that is better optimized for *deserialization*.
This transformation would typically be done as a background task. The
deserializer would be able to (transparently) understand both
the intermediate format and the optimized format."

I can just tell you that it is an excellent idea and we talked with Martin
about it, but I am not sure about how easier it would be. Maybe it is just
easier to have 2 serializers with 2 different goals :)

Regarding "To me it appears like StOMP has better support
for serialization/deserialization "hook"
methods<http://stomp.smalltalk-users.jp/home/how-to-use-stomp/hook-methods>,
class renaming<http://stomp.smalltalk-users.jp/home/how-to-use-stomp/renaming>
and
shape changing<http://stomp.smalltalk-users.jp/home/how-to-use-stomp/shapechangers>.
Hopefully, Fuel can learn from StOMP in this field."   I totally agree.
StOMP's hook methods are awesome and we want to have the same in Fuel. In
fact, check the issue tracker and you will see several open issues
regarding
this :)
I think class renaming and shape changing are fine in Fuel.

Finally, notice that we are not "competitors". We have sent several private
emails between us and Masashi UMEZAWA and we are trying to share as much as
possible.

-- 
Mariano
http://marianopeck.wordpress.com
 
CD: 4ms