出于好奇：CLR如何将虚方法调用分派给接口成员以正确实现？
我知道CLR为每个类型维护一个VTable，其中包含每个方法的方法槽，并且对于每个接口，它还有一个附加的方法槽列表，指向相关的接口方法实现。但我不明白以下内容：CLR如何有效地确定要从类型的VTable中选择哪个接口方法槽列表？
来自MSDN杂志2005年5月号的文章深入了解.NET Framework内部，以查看CLR如何创建运行时对象谈到了一个由接口ID索引的进程级映射表IVMap。这是否意味着同一进程中的所有类型都具有指向相同IVMap的相同指针？
它还说明：
如果MyInterface1由两个类实现，则IVMap表中将有两个条目。该条目将指回嵌入在MyClass方法表中的子表的开头。
CLR如何知道要选择哪个条目？它会进行线性搜索以找到与当前类型匹配的条目吗？还是二进制搜索？或者某种直接索引并具有可能存在许多空条目的映射？
我也阅读了《CLR via C# 3rd edition》中关于接口的章节，但它没有涉及到这一点。因此，这个问题的其他答案 的答案并不能解答我的问题。
这里有一点重要的考虑，直接来自于文章：
当调度存根失败的次数足够多时，调用站点被认为是多态的，解析存根将会回溯调用站点，直接指向解析存根，以避免持续失败的调度存根的开销。在同步点（目前是 GC 的末尾），多态站点将随机升级回单态调用站点，假设调用站点的多态属性通常是临时的。如果对于任何特定的调用站点，这个假设是不正确的，它将很快触发回溯，将其降级为多态。
运行时对单态调用站点非常乐观，在实际代码中这非常合理，并且会尽可能地避免使用解析存根。
如果你看一下链接站点上的图表，它可能会更容易理解。
这是不是意味着同一进程中的所有类型都具有指向相同IVMap的指针？
是的，因为它在域级别上，这意味着该AppDomain中的所有内容都具有相同的IVMap。
CLR如何知道要选择哪个条目？它是否执行线性搜索以查找与当前类型匹配的条目？还是二进制搜索？或者进行某种直接索引并具有其中可能有许多空条目的映射？
类是通过偏移量布局的，因此每个东西都具有相对固定的区域。当查找方法时，这使事情变得更容易。它将搜索IVMap表，并从接口中查找该方法。从那里，它转到MethodSlotTable并使用该类对接口的实现。该类的接口映射保存元数据，但是实现与任何其他方法一样处理。
再次来自你链接的网站：
每个接口实现都将在IVMap中具有一个条目。如果MyInterface1由两个类实现，则IVMap表中将有两个条目。该条目将指向嵌入在MyClass方法表中的子表的开头。
这意味着每次实现接口时，它在IVMap中都有唯一记录，该记录指向MethodSlotTable，后者又指向实现。因此，根据调用它的类，它知道要选择哪个实现，因为IVMap记录指向调用该方法的类中的MethodSlotTable。因此，我想它只是通过IVMap进行线性搜索以找到正确的实例，然后就可以运行了。
编辑：提供有关IVMap的更多信息。
同样来自OP中的链接：
第一个InterfaceInfo条目的前4个字节指向MyInterface1的TypeHandle（参见图9和图10）。下一个字（2个字节）由Flags占用（其中0从父项继承，1在当前类中实现）。 Flags之后的WORD是Start Slot，它由类加载器用于布置接口实现子表。
因此，这里我们有一个表格，其中数字是字节的偏移量。这只是IVMap中的一个记录：
+----------------------------------+
| 0 - InterfaceInfo |
+----------------------------------+
| 4 - Parent |
+----------------------------------+
| 5 - Current Class |
+----------------------------------+
| 6 - Start Slot (2 Bytes) |
+----------------------------------+
假设在该 AppDomain 中有 100 个接口记录，我们需要为每一个记录找到实现。我们只需比较第5个字节，以查看它是否与我们当前的类匹配，如果匹配，则跳转到第6个字节的代码。由于每个记录长8个字节，因此我们需要进行以下操作：（伪代码）
findclass :
if (!position == class)
findclass adjust offset by 8 and try again
虽然它仍然是一种线性搜索，但实际上，由于要迭代的数据规模并不是很大，所以不会花费太长时间。希望这能有所帮助。
编辑2：
所以，在查看图表并想知道为什么类图中没有Slot 1在IVMap中之后，我重新阅读了该部分并找到了以下内容：
IVMap是根据方法表中嵌入的接口映射信息创建的。接口映射是在MethodTable布局过程中基于类的元数据创建的。一旦类型加载完成，只使用IVMap进行方法调度。
因此，类的IVMap仅加载其继承的接口。它似乎从域IVMap复制，但仅保留指向的接口。这引出了另一个问题，如何？很可能它与C++的vtable相同，其中每个条目都具有偏移量，并且接口映射提供要包括在IVMap中的偏移量列表。
如果我们看一下可能适用于整个域的IVMap：
+-------------------------+
| Slot 1 - YourInterface |
+-------------------------+
| Slot 2 - MyInterface |
+-------------------------+
| Slot 3 - MyInterface2 |
+-------------------------+
| Slot 4 - YourInterface2 |
+-------------------------+
mov ecx,edi
mov eax, dword ptr [ecx]
mov eax, dword ptr [ecx+08h] ; slot 2
; do stuff with slot 2
mov eax, dword ptr [ecx+10h] ; slot 3
; do stuff with slot 3
从您提供的第一篇文章中：
如果MyInterface1由两个类实现，则IVMap表中将有两个条目。该条目将指向嵌入在MyClass方法表中的子表的开头，如图9所示。
以及
ClassLoader遍历当前类、父类和接口的元数据，并创建方法表。在布局过程中，它替换任何被覆盖的虚拟方法，替换任何被隐藏的父类方法，创建新的插槽，并根据需要复制插槽。复制插槽是必要的，以创建每个接口都有自己的迷你vtable的假象。但是，复制的插槽指向与类自己的vtable条目相同的物理实现。
这让我想到接口的IVMap具有由类名（或某个等效项）键控的条目，指向类的vtable的子部分，该子部分基本上具有实现该接口的类的每个方法的重复实现，由指向与类自己的vtable条目相同的物理实现的指针支持。
不过，我的理解可能完全错误。