Hi Chris,
Sorry for my delay, thank you very much for your answer and for the tips about benchmarking. I also agree in that both serializers have different purposes and so different features and limitations and so looking who is the fastest is not the best comparison.
Another question: have you benchmarked the memory use while serializing or materializing? I have never. I know that there is something called SpaceTally but I don't know about it.
Cheers, Martin
On Fri, Jun 3, 2011 at 1:30 PM, Chris Muller ma.chris.m@gmail.com wrote:
- Instantiatation / initialization of a MaObjectSerializer.
- Serialization of object graphs of various sizes.
If you have by chance some code snippets to generate graphs for testing (maybe you have that in Magma) let us know :) We can a pice of code that generates binary trees...
Yes, see MaFixtureFactory.
MaFixtureFactory current samples
or
MaFixtureFactory current knot
There was a discussion recently about comparing object graphs -- you may be interested in MaObjectSerializerTester, and how it verifies serialized-->remateralized object graphs of any shape against the original fixture graph. Very useful for ensuring your serializer is _working_. :) See MaObjectSerializerTestCase>>#testSamples which sends #maEquivalentForSerializationTest: to determine that..
"Serialization" | obj ser | obj := Array with: 1 with: 'string'. ser := MaObjectSerializer new. [ ser serializeGraph: obj ] bench
With the rest of the serializers that we do is to serialize the graph
into a
file. How could we do this with Magma Serializer? because serializeGraph: answers a MaSerializedGraphBuffer. So, I guess I
can
ask the byteArray to it and do a nextPutAll: or something like that to
our
stream?
Yes. I, of course, always appreciated the elegance of the notion that MaObjectSerializer could operate directly on Streams, but the problem is that I also want a secure client-server protocol which wraps the serialized requests and responses. So to, for example, calculate a MAC, the full byteArray of the request is required in advance. It's ok though, serialized / materialized objects have to fit into memory anyway, so a streaming API doesn't really offer any practical advantage - just elegance.
We also have in Fuel what we call "in memory serialization" that
basically
returns the byteArray and then we can materialize from that. So this case would be similar to this usage of Magma, wouldn't it ?
Yeah - similar to use of "Ma object serializer". (IOW, you don't have to load Magma to use MaObjectSerializer), you can just load MaBase.
As I said, benching is tricky, and publishing comparisons even trickier
yes, exactly. The problem is in addition that there are supported
features
of a serializer that inpacts on the results of a benchmark. For example, supported class reshapes, initialization after materialization, support transient instVars...etc... to support all those things you usually spend more time. So maybe you support all that and in the results you are
slower
in comparisson with someone that do not support that. So yes, measuring speed only is not good. But taking into account the rest of the
properties
is better.
Yip! Glad you said that.
- Chris