Closed redknightlois closed 4 years ago
Given that the method is not inlined and those "directives" are classes rather than structs there's no (reasonable) way to optimize this. This trick requires structs to work the way you want it to work.
I'll try that with structs in a few hours and see if it works.
The struct trick did it. Probably this should be documented properly :) BTW the assembler emitted now is "beautiful" :dart:
When the type is instantiated based on non value-types, shared code is generated which is not possible to specialize for the particular type. Hence you saw the code that was required to do runtime type checking to determine which branch to execute. However when the type was a value-type, the runtime creates specialized generic methods for the type. The JIT in morph has an optimization to fold away such checks at code-generation time and eliminate the branch. Closing this as this is the expected behavior.
For some reason this code is not being optimized:
As you can see in the assembler, it should have evicted the whole thing when generating the code for this method. What it is strange is that TTableType is known at the caller site to be a constant already.
And do the call with something like this instead:
So the question remains, could it be the way I am defining the 'directive' classes the problem?
I know this is a somewhat 'unorthodox' use of C# generics, but it is just too tempting to be able to optimize an algorithm that we need it to be portable without having to write C++ for all the architectures supported by CoreCLR.
@CarolEidt If you want to look for potential general optimization opportunities, the actual code can be found at: https://github.com/Corvalius/ravendb/blob/lz4-131/src/Sparrow/Compression/LZ4.cs