Key changes / goals:
- Generics: for the most part, gone from the guts of the implementation; it now uses a non-generic "decorator" approach - you wouldn't believe how much pain they have caused me (here)
- This should hopefully fix compact-framework (here, here), and might (no promises at this stage) even allow it to work on .NET 1.1 and micro-framework
- Build around a runtime model rather than attribute reflection (but with attribute reflection to be added as a model provider)
- Much easier to unit-test individual decorators
- Double implementation; vanilla decorator for "light" frameworks, and compiled implementation for the full-fat versions
- I lack the hardware to test, but I'm hopeful that the vanilla decorators will work on iPhone - I don't suppose you have an iPhone and iMac to spare?
- Potential to emit the compiled version to disk (think: sgen)
- Added buffer-pooling (makes it possible to use a larger buffer with minimal allocation costs)
- Re-written the string handling to use pointer (unsafe) code where appropriate, and better incremental encoder handling
There is still masses to do - but I'm feeling pretty happy with the initial results... I've got the core engine in place, and enough decorators to write some basic messages. Timings below, with meanings:
- New (decorator) - vanilla decorator implementation - no optimisations (yet; although I'm sure we can improve this once I can tell what works/where)
- New (compiled) - compile/flatten the decorators into a single operation
- New (delegate) - same, but to a delegate rather than class (just for fun)
- Old: the existing protobuf-net "generic" Serializer
New (decorator): 3399ms
New (compiled): 788ms
New (delegate): 619ms
Old: 758ms
New (decorator): 2569ms
New (compiled): 642ms
New (delegate): 604ms
Old: 754ms
New (decorator): 2549ms
New (compiled): 631ms
New (delegate): 623ms
Old: 740ms
New (decorator): 2589ms
New (compiled): 640ms
New (delegate): 608ms
Old: 750ms
New (decorator): 2587ms
New (compiled): 638ms
New (delegate): 614ms
Old: 750ms
New (decorator): 2433ms
New (compiled): 519ms
New (delegate): 504ms
Old: 664ms
New (decorator): 2318ms
New (compiled): 512ms
New (delegate): 506ms
Old: 596ms
Oh, and I need to fix all the other things, too... sigh.
5 comments:
Hi,
There seem to be a number of
implementations for .NET available.
How safe is it to use your implementation? Would you suggest it for use in a real project?
I see you might support the .NET micro framework, that would be really cool :p
The v1 download is pretty solid; there are a few known edge cases, but it is being used by a good number of real projects.
The v2 stuff is barely "hello world" at the moment; don't touch that.
I can't *guarantee* MF, but we'll see.
Hi Marc,
I am in the early stages of looking into cross platform (mostly Java, C#, C++) serialization options and came across your c# implementation.
Do you have, or plan to support, different "formatters" - namely JSON and XML, on top of the binary format?
Thrift claims they have that, but I was put off by the lack of documentation and was thinking to give protobuf a shot
Well, most of the *point* seems to be the wire format. There are already perfectly good answers for json and xml...? In short - no, that isn't something I had on my "todo" list - but I'm open to reasons that it should be?
In Thrift there is a nice abstraction - Protocol, separating data structure, from transport (which allows for pluggable data encodings).
Here is doc which explains it nicely:
http://incubator.apache.org/thrift/static/thrift-20070401.pdf
I think the Protocol generalization is very nice - can expose the same service in binary, json, xml, using the same technology. I can see it being useful at least for debugging.
PS:
I am not aware of a tool which supports JSON, XML, and binary out of the box supporting at least java and c#.
I have used XStream for xml and json, but this is only java.
Post a Comment