Performance different for nested generic type?

[cathei]

While I was experimenting with alloc-free Linq implementation, I found some interesting behavior, when I call generic method in pattern like GenericMethod<GenericStruct<Class>>, the benchmark performance went exceptionally poor.

I did some experiment and made a small reproducible example. I used SharpLab to inspect JitAsm from this code:

using SharpLab.Runtime;

public interface IMyInterface
{
    public int GetValue();
}

class MyClass<T> : IMyInterface
{
    public int GetValue() => 7;
}

struct MyStruct<T> : IMyInterface
{
    public int GetValue() => 3;
}

[JitGeneric(typeof(MyClass<int>)),
 JitGeneric(typeof(MyClass<object>)),
 JitGeneric(typeof(MyStruct<int>)),
 JitGeneric(typeof(MyStruct<object>))]
public class GenericClass<T> where T : IMyInterface
{
    public static int Test(T obj)
    {
        return obj.GetValue();
    }
}

Then I get this result:

GenericClass`1[[System.__Canon, System.Private.CoreLib]].Test(System.__Canon)
    L0000: sub rsp, 0x28
    L0004: mov rcx, rdx
    L0007: mov r11, 0x7ffb48867000
    L0011: call qword ptr [0x7ffb48867000]
    L0017: nop
    L0018: add rsp, 0x28
    L001c: ret

GenericClass`1[[System.__Canon, System.Private.CoreLib]].Test(System.__Canon)
    L0000: sub rsp, 0x28
    L0004: mov rcx, rdx
    L0007: mov r11, 0x7ffb48867000
    L0011: call qword ptr [0x7ffb48867000]
    L0017: nop
    L0018: add rsp, 0x28
    L001c: ret

GenericClass`1[[MyStruct`1[[System.Int32, System.Private.CoreLib]], _]].Test(MyStruct`1<Int32>)
    L0000: mov eax, 3
    L0005: ret

GenericClass`1[[MyStruct`1[[System.__Canon, System.Private.CoreLib]], _]].Test(MyStruct`1<System.__Canon>)
    L0000: sub rsp, 0x28
    L0004: mov [rsp+0x20], rcx
    L0009: mov [rsp+0x38], rdx
    L000e: mov rdx, [rcx+0x30]
    L0012: mov rdx, [rdx]
    L0015: mov rax, [rdx+0x10]
    L0019: test rax, rax
    L001c: je short L0020
    L001e: jmp short L002f
    L0020: mov rdx, 0x7ffb4886e7a8
    L002a: call 0x00007ffb9c2b2740
    L002f: lea rcx, [rsp+0x38]
    L0034: call rax
    L0036: nop
    L0037: add rsp, 0x28
    L003b: ret

The first two is for class and shares same code made with __Canon, which is understandable. Third example is inlined, which is ideal. But forth one! This creates huge chunk even though generic argument is not used at all in MyStruct. Can anyone share the knowledge of what might have caused this? Thank you!

Edited: Update example for readability

[cathei]

After some research, I found a code from this question:

using SharpLab.Runtime;

[JitGeneric(typeof(int))]
[JitGeneric(typeof(object))]
public class A<T>
{
    public static int X;

    public static class B
    {
        public static int C() => X;
    }
}

That also generates similar pattern of assembly:

A`1+B[[System.Int32, System.Private.CoreLib]].C()
    L0000: mov ecx, 0x1b43c650
    L0005: xor edx, edx
    L0007: call 0x0f585a70
    L000c: mov eax, [eax+4]
    L000f: ret

A`1+B[[System.__Canon, System.Private.CoreLib]].C()
    L0000: push ebp
    L0001: mov ebp, esp
    L0003: push eax
    L0004: mov [ebp-4], ecx
    L0007: mov edx, [ecx+0x20]
    L000a: mov edx, [edx]
    L000c: mov edx, [edx+8]
    L000f: test edx, edx
    L0011: je short L0015
    L0013: jmp short L0021
    L0015: mov edx, 0x1b43d35c
    L001a: call 0x0f429aa0
    L001f: mov edx, eax
    L0021: mov ecx, edx
    L0023: call 0x0f409940
    L0028: mov eax, [eax+4]
    L002b: mov esp, ebp
    L002d: pop ebp
    L002e: ret

And from the answers I could assume that it is trying to access method table using the type parameters, because it is accessing different type A<T> from the called type A<T>.B. What would be the good way to avoid this? One way I can think of is wrapping reference type to value type with object field and downcast with Unsafe.As when I need it, but it would make me lose generic constraint information.

[EgorBo]

What would be the good way to avoid this?

Avoid using static fields in generic classes? It has to do a runtime lookup + static initialization if needed

[cathei]

Hello, @EgorBo! Thanks for reply.
In my original example I was not using static fields, only nested generic and generic constraint to the interface. I was building alloc-free Linq library (as a hobby project), so not using nested generic would not be an option. But now I'm getting convinced that I should consider code generator instead of generics.

[EgorBo]

In your original example

public interface IMyInterface
{
    public int GetValue();
}

struct MyStruct<T> : IMyInterface
{
    public int GetValue() => 3;
}

public class GenericClass<T> where T : IMyInterface
{
    [MethodImpl(MethodImplOptions.NoInlining)]
    public static int Test(T obj)
    {
        return obj.GetValue();
    }
}

GetValue should be inlined to avoid unnecessary runtime lookup, but unfortunately, due to a limitation in JIT's inliner it's not happening. There is an issue already for it somewhere.

But now I'm getting convinced that I should consider code generator instead of generics.

Always a better choice and AOT friendly ;-)

[am11]

@cathei thanks for actually developing LinqGen source generator project! I remember reading this conversation last year and recently finding out about LinqGen. 🙂
ps - interceptor support will make the usage seamless for existing C# projects heavily relying on LIINQ. 🚀