Compiler abstraction about wire

[rogeralsing]

btw. offtopic but still related :-)
AFAIK NetSerializer is the fastest binary serializer in the world for .NET.
Using the POCO class in the perf test, Wire actually out performs it, and all the other serializers too.

Results change if the serialized object is smaller though.

[rogeralsing]

Any feedback on how we can improve this is welcome.

One thing that I am not sure how to solve is the concept of "Constant" in expressions, where you can bind an expression to an already existing object.
How would one go about to make the generated IL code get access to the external object?
it needs to be stored somewhere so the IL code can get to it I suppose.

[rogeralsing]

Related to #42

[rogeralsing]

cc @Scooletz I am working on an IL implementation of the ICompiler abstraction.
it can emit methods and some code already. but far from complete.
please have a look and see
https://github.com/akkadotnet/Wire/blob/dev/Wire/Compilation/IlExpression.cs
https://github.com/akkadotnet/Wire/blob/dev/Wire/Compilation/IlCompiler.cs
https://github.com/akkadotnet/Wire/blob/dev/Wire.Tests/IlCompilerTests.cs

Do you think this is something we can work with? at least as a start to get going?

I'm hesitant to bring in Sigil as that will bring more dependencies. I would like to stay clean and lightweight. and the code we need to generate is not that complex.

[Scooletz]

I took a quick look. It looks promising and yes, I wouldn't bring in Sigil. I was referring to it only as a good approach towards emitting. Another one would be the EmitContext from protobuf-net. Your proposal looks very good as well.
I'm taking a few days off but will try to catch up either today in the evening (GMT+2) or tomorrow (evening as well).

[rogeralsing]

IlCompiler is now complete enough that it can compile the _read and _write in the session aware/unaware serializers.

it still causes "destabilize runtime" if used on the read and write generators in DefaultCodeGenerator.
I guess there is some issue with boxing/unboxing.

[Scooletz]

I've got a few questions after reading the code more carefully:

1. Is IlCompiler<Del> is meant to replace Compiler<Del> at the end?
2. Does is suffer from the "destabilize runtime" still? Tests on dev are all green.
3. Have you checked if the static calls for the primitive value serializered are inlined? If not, I'll check it with BenchmarkDotNet. It seems to me that it's the last thing we could improve for primitive serializers.

[rogeralsing]

1. That was the idea, but I'm not sure if the effort is worth it (?)
2. There seems to be some strangeness still going on, it actually makes the testrunner stop before all tests are done. not sure exactly what makes it blow up yet. (when using the IlCompiler instead of Combiler inside DefaultCodeGenerator)
3. I'm not sure how to check that they are inlined as inlining only affects the Jitter (afaik). adding aggressive inlining to the the static methods seems to do nothing for the perf.

If the inlining does not occur, I think it would be possible to do it in the Emit phase, right?

[Scooletz]

I'm mostly offline this week but will take a look next week and try to finalize this approach. I think that JIL optimization, ordering properties by type to get a better memory alignment could bump up the perf again.