- 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