Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

public sealed class MyClass
{
    private readonly ISpanFormattable _formattable;

    public MyClass(ISpanFormattable formattable)
    {
        _formattable = formattable;
    }

    public string FormatToString() => _formattable.Format(format: null, provider: null);
}

namespace System.Runtime.CompilerServices;

public readonly struct InterfaceDispatchCache<T>
    where T : class
{
    public readonly T Instance;

    public InterfaceDispatchCache(T instance); // actual implementation is provided by the runtime depends on actual type T
}

[StructLayout(LayoutKind.Sequential)]
public readonly struct InterfaceDispatchCache<ISpanFormattable>
{
    public readonly ISpanFormattable Instance; // always at offset 0
    private readonly void* method0; // pointer to ISpanFormattable.TryFormat method implementation
    private readonly void* method1; // pointer to IFormattable.Format method implementation

    public InterfaceDispatchCache(ISpanFormattable instance) // runtime-generated ctor
    {
        Instance = instance ?? throw new ArgumentNullException(nameof(instance));
        method0 = ldvirtftn instance.TryFormat; // pseudo code using existing ldvirtftn IL opcode
        method1 = ldvirtftn instance.Format
    }
}

InterfaceDispatchCache<ISpanFormattable> cache = ...;
cache.Instance.Format(format: null, provider: null); // converted to 'call cache.method1'

public sealed class MyClass
{
    private readonly InterfaceDispatchCache<ISpanFormattable> dispatchCache;

    public MyClass(ISpanFormattable formattable)
    {
        dispatchCache = new(formattable);
    }

    public string FormatToString() => dispatchCache.Instance.Format(format: null, provider: null);
}

It's an interesting idea, but what about just allow taking the pointer to an instance method? Then you could take the pointer to the method through the instance and cache it as needed, and do it on an individual basis rather than every single method in the interface(s). I imagine it would even be able to speed up virtual calls as well as interface calls since the v-table lookup would happen once, then you use the pointer directly.

Also, I don't see how this will work with mutable structs, since you have to copy the struct to store in the field. (Looking at generics. Obviously there is no reason to use this on known structs.) [Edit] I see you put a class constraint.

@timcassell I thought about that to extend delegate*<> syntax for instance methods. But I found that it is not possible to represent dynamic dispatch of interface method as some static construct that can be verified and checked by the compiler.

Let's imagine that we have delegate* thiscall<> syntax for instance methods:

IFormattable fmt = ...;
delegate* thiscall<IFormattable, string, IFormatProvider, string> ptrToFormatMethod = &fmt.ToString;

this argument is explicit in this approach, there is no way to check that I calling the method exactly for the same object as used for method resolution.

Then you could take the pointer to the method through the instance and cache it as needed

It can be done currently using delegates. But delegate requires allocation. Otherwise, we need some version of delegate in the form of value type, or something like dotnet/csharplang#3452. I don't want to interfere with other proposals.

@timcassell I thought about that to extend delegate*<> syntax for instance methods. But I found that it is not possible to represent dynamic dispatch of interface method as some static construct that can be verified and checked by the compiler.

Why does it have to be verified by the compiler? Function pointers require unsafe code, the onus should be on the programmer to use the same instance that was used to get the pointer.

Why does it have to be verified by the compiler?

Here you go:

interface I
{
   void M();
}

class A : I
{
   void M() { }
}

class B : I
{
  void M() { }
}

I a = new A();
delegate* thiscall<I, void> methodPtr = &a.M;
a = new B();
methodPtr(a);

methodPtr points to A.M() but it's called with an instance of B. It is completely unsafe because A.M() expects another memory layout and fields which are not compatible with B in real life. In other words, it's non-obvious and error-prone way to reinterpret this argument for instance method which make no sense in most situations.

Right, I understand the unsafe-ness of it. But my point is it has to be used in an unsafe context, and there are plenty of ways for programmers to shoot themselves in the foot with unsafe code, so why is this case different?

[Edit] Also, your own proposal could have the same issue happen if the struct gets torn.

Also, your own proposal could have the same issue happen if the struct gets torn.

This is why I don't propose it for structs.

here are plenty of ways for programmers to shoot themselves in the foot

Correct, but it's not a reason to add a new one

This is why I don't propose it for structs.

I'm talking about the InterfaceDispatchCache struct.

Correct, but it's not a reason to add a new one

No, the reason is performance, of course. The unsafe-ness is just a reason not to add it. But it doesn't seem more unsafe than other unsafe features to me.

The unsafe-ness is just a reason not to add it

Not the only one. Convenience too. Individual pointer for each method requires a lot of boilerplate code. Actually, I can do the same right now with delegates or even IL weaving (e.g. InlineIL weaver). Does presence of IL weaving should prevent introduction of new low-level API? I hope not. People use IL weaving as a last resort, because they have no choice (and me too).

Actually, I can do the same right now with delegates or even IL weaving (e.g. InlineIL weaver). Does presence of IL weaving should prevent introduction of new low-level API? I hope not. People use IL weaving as a last resort, because they have no choice (and me too).

I actually didn't know that instance method pointers are already supported in IL. I tend to avoid using IL directly since not every runtime supports all instructions (looking at Unity's IL2CPP).

Individual pointer for each method requires a lot of boilerplate code.

Sure, but I'd rather be able to be fine-grained about it when I'm focused on optimal efficiency.

And I think it wouldn't hurt to be able to optimize virtual calls the same way you are proposing to optimize interface calls.

actually didn't know that instance method pointers are already supported in IL

Yes, they are. method instance void *(object) as TypeDescr and calli instance void(object) for indirect call (CallSiteDescr).

t wouldn't hurt to be able to optimize virtual calls

I don't think that it's needed. Virtual method has known offset in vtable at the time of compilation (JIT or AOT) while interface method should be resolved dynamically through multiple indirections. So virtual method call is already optimized by runtime as call dword ptr [vtable_address+virtual_method_slot_index] with single level of indirection.

I don't think that it's needed. Virtual method has known offset in vtable at the time of compilation (JIT or AOT) while interface method should be resolved dynamically through multiple indirections. So virtual method call is already optimized by runtime as call dword ptr [vtable_address+virtual_method_slot_index] with single level of indirection.

Out of curiosity, I went ahead and benchmarked a virtual call against a function pointer call (static instead of instance, since it would be too cumbersome to create a benchmark from IL, but I suspect the performance should be similar).

It looks to be ~73% faster on my machine. So I think it would be worth it. (For reference, I previously benchmarked interface calls to be ~2x slower than virtual calls).

public unsafe class Benchmark
{
    private abstract class Base
    {
        public abstract void CallVirt();
    }

    private class A : Base
    {
        public override void CallVirt() { }
    }

    private class B : Base
    {
        public override void CallVirt()
        {
            throw new NotImplementedException();
        }
    }

    private Base instance;
    private delegate*<Base, void> _fPtr;

    [GlobalSetup]
    public void Setup()
    {
        instance = new A();
        _fPtr = &FuncStatic;
    }

    [Benchmark]
    [MethodImpl(MethodImplOptions.NoOptimization)]
    public void CallFuncPtr()
    {
        _fPtr(instance);
    }

    [Benchmark]
    [MethodImpl(MethodImplOptions.NoOptimization)]
    public void CallVirt()
    {
        instance.CallVirt();
    }

    private static void FuncStatic(Base instance) { }
}

Hmm, interesting observation. Probably, it happens because the object header doesn't store vtable, instead it stores a pointer to type information with vtable, and we have another indirection:

public class C {
    public virtual void M() {
    }
    
    public static void S(C obj) => obj.M();
}

C.S(C)
    L0000: push ebp
    L0001: mov ebp, esp
    L0003: mov eax, [ecx] ; ecx stores object reference, so [ecx] stores a pointer to type info
    L0005: mov eax, [eax+0x28] ; obtains a pointer to vtable stored in type info
    L0008: call dword ptr [eax+0x10] ; offset to appropriate slot in vtable
    L000b: pop ebp
    L000c: ret

3 indirections (at least on x64) are needed to reach actual implementation of virtual method. Too many indirections also break data locality and increase a chance of CPU cache miss. In that case it's reasonable to extend the original proposal.

Is this addressed by #111771?