NetSerializer LargeStruct test perf about wire

[rogeralsing]

Ok, I found the issue, we lacked handling for valuetypes when creating new objects so it fell back onto the FormattingServices.GetEmptyObject.

Still slower than NetSerializer here but I'd say that is expected as we carry more state around.

[rogeralsing]

Twice as slow might have been over exaggerated, 1.5 times slower is more correct.
400 ms vs 600 ms.

Changing it to a class brings it down to 550, but still significantly slower than NetSerializer.
also, it is only the serialize step that is slower, deserialize is actually faster.

[Scooletz]

Nice finding. Will take a look at it.
Just to be specific:

• there are 4 virtual calls
• bit converter calll should look like NoAllocBitConverter.GetBytes(x.field1,buffer)

[rogeralsing]

4?
The primitives are inlined into the ICompiler pipeline arnt they? EmitWrite.
That leaves just the outer function to write the entire struct, or am I missing something now?

[Scooletz]

4 calls to Stream.Write which is virtual.

[tomba]

Are there any specific tricks NetSerializer uses in terms of structs?

No, I don't think so (well, there's "direct serialization", but that's not relevant here).

You can actually make NetSerializer emit an assembly dll file containing all the generated code, by doing a debug build and uncommenting the "GenerateDebugAssembly" line in Test/Tester.cs. That assembly can't be used as such, but you can dissassemble it, which I've found a great way to understand issues.

[rogeralsing]

I've got it down to only differ with some 50ms.
I realized that we do not need to lookup known types while serializing to determine if we need to write manifest or not.
We can simply create an object serializer that never writes the manifest if the type is known when the serializer is generated and register that into our serializer lookup.
This made known type serialization a lot faster.

[rogeralsing]

Closing this one, the perf is good enough in the current code