Messagepack-csharp: Custom Message Constructor

[williamkmlau]

Hi neuecc,

This issue/feature request is related to #152 #110 #107 , but is with a much easier approach to solve the same problem.

It is very important to reuse objects because no matter how memory efficient the Serialize/Deserialize is, if we have to throw away all the created objects it will still be very wasteful memory allocation.
This is the main reason why we need to deserialize into an existing object, so we can reuse an old message object from a pool.

Instead of modifying and extending the interface to support a new method DeserializeTo, I think a much easier approach is to allow us to define a custom object create function which replaces the objInfo.GetConstructorString() in the code generator. Such as adding a new attribute tag for a function that defines how to create the object and is picked up by the code generator.

[MessageConstructor]
public static MessageType Create(){
    return MessageTypePool.Pop();
}

As Example Protobuf-net's RuntimeTypeModel.SetFactory is very helpful for implementing object pools to be used with deserialization. If we can have something similar, which replaces the new object Constructor line in the current code generator it will be the most versatile and don't require any interface change. We can then simply handle Collections recycling using custom formatters or modifying the source formatter.
This of course does not allow for the MergeTo feature, but I believe Merging collections have a much rarer use case than message object pooling.

[williamkmlau]

I implemented this feature now. Let me know if you want to see it as a pull request.

[wjax]

@williamkmlau is it threadsafe? You must have into account the objects lifetime. Or manage what threads are requesting them

[AArnott]

If MessagePack supports object recycling, we wouldn't do it through statics because that precludes the option for code to maintain independent pools. Not every use case is an app-wide one.
In v2.0 we have the new MessagePackSerializationOptions class that gets passed around for immutable data and we have MessagePackReader/MessagePackWriter in which we can store mutable per-job data. So I think v2.0 is better positioned to solve a problem such as this.

We already have #107 that requests object recycling, so I'll close this as a duplicate of #107.