Performance of protobuf-net vs. protobuf-csharp-port

I know the features and design of both libraries but I haven't found any direct performance comparison between those two. Both are definite开发者_开发问答ly great libs. Regarding the design I think protobuf-csharp-port should be slightly faster due to less reflection, right?

Furthermore:

• When will protobuf-net V2 be released? Any plans, Marc?
• Will there be a new version of protobuf-csharp-port, Jon?

Thank you.

Re performance; protobuf-net is designed to perform that reflection as little as possible, creating efficient data access code after that. In v2, it takes this much further in many ways - using much lower-level meta-programming, and if you want it (entirely optional), pre-generation of a standalone serializer dll - so at runtime the reflection cost is somewhere between minimal (if using runtime meta-programming) to nil (if using pre-generation).

Re release; "when it is ready"; life is crazy hectic, but an alpha dll is available for both full .NET and iPhone (this latter will probably work on most of the lighter runtimes, since iPhone is the most restrictive). Ultimately, reality is that (as unsponsored, etc) it is going to lag a bit behind things like work and family - I try to find time when I can, though.

I think a more sensible comparison is the goals; protobuf-net is designed to be easily fitted onto your existing DTO or domain model, without significant rework - or for use in a code-first scenario. It also supports generation from .proto, but that isn't the primary goal (but is of course hugely desirable). It also sports a very different API, geared around common .NET metaphors, rather than common protobuf metaphors.

Or to put it another way:

• protobuf-csharp-port focuses on protobuf, and adds C# / .NET to the existing protobuf landscape
• protobuf-net focuses on C# / .NET, and adds protobuf to the existing C# / .NET landscape

A subtle distinction, maybe - and indeed either would make a worthy serialization API for .NET.

As a corollary, if your primary aim is interop between heterogeneous environments that you actively work on in the same team - then maybe protobuf-csharp-port is a better match for you.

I'm also a bit... "loose" with protobuf, so I have no (well, minimal) guilt going a little bit beyond the standard spec (while staying inside the protocol definition) to shoehorn in inheritance, full-graphs, etc - which are common in the .NET ecosystem but have no direct map in protobuf. And of course I can look more at tools like WCF (and to a lesser degree: remoting).

When I use protobuf-csharp-port, I found a bug in this lib. For example, when I create message like this:

    message CalculateInfo{
    required string CalStarttime=1;
    optional string CalEndtime=2;
    required string Smiles=3;
    optional string CAS=4;
    optional string ChName=5;
    optional string EnName=6;
    required string Param=7;
    required bytes Result=8;
    required bool IsFinished=9;
}

    message GetAllCalulateResponse{
        required bool  isSuccessful = 1;
        required int32 Count=2;
        repeated CalculateInfo History=3;

    }

code like this(in python):

msg_resp.Count = len(resultSets)

calculateInfo = [None] * msg_resp.Count
cnt = 0
for result in resultSets:
    calculateInfo[cnt] = msg_resp.History.add()
    calculateInfo[cnt].CalStarttime = str(result.calculateStartTime)
    calculateInfo[cnt].CalEndtime = result.calculateEndTime.strftime('%Y-%m-%d %X')
    calculateInfo[cnt].IsFinished = result.isFinished
    calculateInfo[cnt].Param = result.paramInfo
    calculateInfo[cnt].Result = str('ff'*1000) #result.result

    calculateInfo[cnt].Smiles = result.smilesInfo.smilesInfo
    calculateInfo[cnt].CAS = result.smilesInfo.casInfo

    nameSets = CompoundName.objects.filter(simlesInfo=result.smilesInfo.pk,isDefault=True)
    for nameSet in nameSets:
        if nameSet.languageID.languageStr == Chinese_Name_Label:
            calculateInfo[cnt].ChName = nameSet.nameStr 
        elif nameSet.languageID.languageStr == English_Name_Label:
            calculateInfo[cnt].EnName = nameSet.nameStr

    cnt = cnt +1 

C# code will occur this error: While parsing a protocol message, the input ended unexpectedly in the middle of a field. This could mean either than the input has been truncated or that an embedded message misreported its own length.

when I small calculateInfo[cnt].Result, it works again.