ILEmit serializers like protobuf-net does
Scooletz opened this issue · comments
A performance gain can be provided not only by reducing allocations or providing a better wire format but also by optimizing the serializer methods themselves. It has been applied in protobuf-net (they have their own il emit context) as in JIL which uses Sigil. Is this kind of optimizations considered for the future releases of the wire? What's your opinion on this kind of optimizations ?
I'm not sure I follow, we already do code generation using linq.Expressions CompileToDelegate.
Which is doing il emit behind for you.
I'm sorry. I should have been more specific. What I meant was the protobuf ability to actually inline the serializers as well, as they provide this two specific methods: https://github.com/mgravell/protobuf-net/blob/master/protobuf-net/Serializers/IProtoSerializer.cs#L49-L67 . I can see in the default compiler that the object serializer itself is emitted, but still boxing for its value type properties occur as the WriteObject method uses a serializer and an object. My question was about going one lvl deeper and emitting away the serializer methods. This would allow us to do not box at all in a protobuf-inspired manner :)
Ah yes, I will dig into this and see if there is any fairly easy way to adapt the current coded to do this.
That being said, the getters and setters of values are fairly insignificant compared to touching the input/output stream, and looking up types/object identitiers or translating to and from strings/UTF8.
I have made some good progress on this one.
It doesn't eliminate boxing yet, but at least all the code is generated in a single chunk instead of having layers upon layers of delegates.
This had some dramatic effect on the performance. its now about 20% faster.
Closing this, we have #56 which is in progress already