Of Structs, Layouts, and Serialization

[dvestal]

I have a class that needs to be serialized to a byte buffer. I'm using
a large, unwieldy, homegrown serialization method, which has to change
every time the class's members change, and I think there's probably a
better way.

I could do the job generically, and in just a few lines, by declaring
the class as [Serializable()], then using a BinaryFormatter to
serialize the object to a memory stream, then getting the buffer from
the memory stream. However, that generates a buffer that's much larger
than the actual size of the members in the class.

Is there an easy way of serializing the object to a byte buffer in a
space-efficient way?

[justin creasy]

When you serialize a class using Serializable in .NET I believe it
breaks your class and it's valuables into XML, which is why it becomes
so large. As far as I know, that is the only utility in .NET to
serialize a class, and if you need something smaller you will have to
create it yourself. I feel your pain though as I have to support a
serialization method for a class that changes.

dv*****@gmail.com wrote:

I have a class that needs to be serialized to a byte buffer. I'm using
a large, unwieldy, homegrown serialization method, which has to change
every time the class's members change, and I think there's probably a
better way.

I could do the job generically, and in just a few lines, by declaring
the class as [Serializable()], then using a BinaryFormatter to
serialize the object to a memory stream, then getting the buffer from
the memory stream. However, that generates a buffer that's much larger
than the actual size of the members in the class.

Is there an easy way of serializing the object to a byte buffer in a
space-efficient way?

[Tom Spink]

justin creasy wrote:

When you serialize a class using Serializable in .NET I believe it
breaks your class and it's valuables into XML, which is why it becomes
so large. As far as I know, that is the only utility in .NET to
serialize a class, and if you need something smaller you will have to
create it yourself. I feel your pain though as I have to support a
serialization method for a class that changes.

dv*****@gmail.com wrote:

>I have a class that needs to be serialized to a byte buffer. I'm using
a large, unwieldy, homegrown serialization method, which has to change
every time the class's members change, and I think there's probably a
better way.

I could do the job generically, and in just a few lines, by declaring
the class as [Serializable()], then using a BinaryFormatter to
serialize the object to a memory stream, then getting the buffer from
the memory stream. However, that generates a buffer that's much larger
than the actual size of the members in the class.

Is there an easy way of serializing the object to a byte buffer in a
space-efficient way?

Hi Justin (and OP),

Not if you use the BinaryFormatter. The BinaryFormatter produces a binary
representation of the serialised class, i.e. in machine-readable form.

The reason that the resulting data is larger than simply the members in the
class is because it contains metadata required to deserialise the class
correctly, specifically versioning and type information.

--
Hope this helps,
Tom Spink

Google first, ask later.

[justin creasy]

Hey Tom, he actually is using the BinaryFormatter and his problem is
the overhead created by it. It's a great tool for rapid development,
but many times that overhead can become a big problem. As far as I
know, outside of the BinaryFormatter, the only way to have a low
overhead serialization function is to create it yourself. Please let me
know if I am missing something.

Tom Spink wrote:

justin creasy wrote:

When you serialize a class using Serializable in .NET I believe it
breaks your class and it's valuables into XML, which is why it becomes
so large. As far as I know, that is the only utility in .NET to
serialize a class, and if you need something smaller you will have to
create it yourself. I feel your pain though as I have to support a
serialization method for a class that changes.

dv*****@gmail.com wrote:

I have a class that needs to be serialized to a byte buffer. I'm using
a large, unwieldy, homegrown serialization method, which has to change
every time the class's members change, and I think there's probably a
better way.

I could do the job generically, and in just a few lines, by declaring
the class as [Serializable()], then using a BinaryFormatter to
serialize the object to a memory stream, then getting the buffer from
the memory stream. However, that generates a buffer that's much larger
than the actual size of the members in the class.

Is there an easy way of serializing the object to a byte buffer in a
space-efficient way?

Hi Justin (and OP),

Not if you use the BinaryFormatter. The BinaryFormatter produces a binary
representation of the serialised class, i.e. in machine-readable form.

The reason that the resulting data is larger than simply the members in the
class is because it contains metadata required to deserialise the class
correctly, specifically versioning and type information.

--
Hope this helps,
Tom Spink

Google first, ask later.

[Martin Z]

Really, it shouldn't be too hard to roll-your-own
unsafe-binaryformatter that has no metadata, as long as you didn't mind
not using polymorphism and kept your classes in an a strict tree.
Horribly inappropriate for lobbing complex objects around, but would be
pretty sweet for passing structs around when you know what type to
expect. Just use reflection to iterate across the members (sort
members into an order though since order is undefined), serialize them
each individually into your stream, and call it done. Recurse where
you find a struct or class. The thing would stack-overflow if it
wasn't a strict tree though, and you'd have to use the default
Constructor() for the expected type, so no polymorphism unless you
roll-your-own metadata... but otherwise it should work.

justin creasy wrote:

Hey Tom, he actually is using the BinaryFormatter and his problem is
the overhead created by it. It's a great tool for rapid development,
but many times that overhead can become a big problem. As far as I
know, outside of the BinaryFormatter, the only way to have a low
overhead serialization function is to create it yourself. Please let me
know if I am missing something.

Tom Spink wrote:

justin creasy wrote:

When you serialize a class using Serializable in .NET I believe it
breaks your class and it's valuables into XML, which is why it becomes
so large. As far as I know, that is the only utility in .NET to
serialize a class, and if you need something smaller you will have to
create it yourself. I feel your pain though as I have to support a
serialization method for a class that changes.
>
dv*****@gmail.com wrote:
>I have a class that needs to be serialized to a byte buffer. I'm using
>a large, unwieldy, homegrown serialization method, which has to change
>every time the class's members change, and I think there's probably a
>better way.
>>
>I could do the job generically, and in just a few lines, by declaring
>the class as [Serializable()], then using a BinaryFormatter to
>serialize the object to a memory stream, then getting the buffer from
>the memory stream. However, that generates a buffer that's much larger
>than the actual size of the members in the class.
>>
>Is there an easy way of serializing the object to a byte buffer in a
>space-efficient way?

Hi Justin (and OP),

Not if you use the BinaryFormatter. The BinaryFormatter produces a binary
representation of the serialised class, i.e. in machine-readable form.

The reason that the resulting data is larger than simply the members in the
class is because it contains metadata required to deserialise the class
correctly, specifically versioning and type information.

--
Hope this helps,
Tom Spink

Google first, ask later.

[Tom Spink]

justin creasy wrote:

Hey Tom, he actually is using the BinaryFormatter and his problem is
the overhead created by it. It's a great tool for rapid development,
but many times that overhead can become a big problem. As far as I
know, outside of the BinaryFormatter, the only way to have a low
overhead serialization function is to create it yourself. Please let me
know if I am missing something.

Tom Spink wrote:

>justin creasy wrote:

When you serialize a class using Serializable in .NET I believe it
breaks your class and it's valuables into XML, which is why it becomes
so large. As far as I know, that is the only utility in .NET to
serialize a class, and if you need something smaller you will have to
create it yourself. I feel your pain though as I have to support a
serialization method for a class that changes.

dv*****@gmail.com wrote:
I have a class that needs to be serialized to a byte buffer. I'm
using a large, unwieldy, homegrown serialization method, which has to
change every time the class's members change, and I think there's
probably a better way.

I could do the job generically, and in just a few lines, by declaring
the class as [Serializable()], then using a BinaryFormatter to
serialize the object to a memory stream, then getting the buffer from
the memory stream. However, that generates a buffer that's much
larger than the actual size of the members in the class.

Is there an easy way of serializing the object to a byte buffer in a
space-efficient way?

Hi Justin (and OP),

Not if you use the BinaryFormatter. The BinaryFormatter produces a
binary representation of the serialised class, i.e. in machine-readable
form.

The reason that the resulting data is larger than simply the members in
the class is because it contains metadata required to deserialise the
class correctly, specifically versioning and type information.

--
Hope this helps,
Tom Spink

Google first, ask later.

Justin,

I meant to infer that serialising the class does not necessarily produce
XML. Your post seemed to imply that serialisation produced XML. Using a
BinaryFormatter, no XML is produced.

--
Hope this helps,
Tom Spink

Google first, ask later.