Производительность" прямого " виртуального вызова по сравнению с вызовом интерфейса в C#

вот как выглядит dis-сборка (Ганс прав):

            f.Bar(); // This is faster.
00000062  mov         rax,qword ptr [rsp+20h] 
00000067  mov         rax,qword ptr [rax] 
0000006a  mov         rcx,qword ptr [rsp+20h] 
0000006f  call        qword ptr [rax+60h] 
            f2.Bar();
00000072  mov         r11,7FF000400A0h 
0000007c  mov         qword ptr [rsp+38h],r11 
00000081  mov         rax,qword ptr [rsp+28h] 
00000086  cmp         byte ptr [rax],0 
00000089  mov         rcx,qword ptr [rsp+28h] 
0000008e  mov         r11,qword ptr [rsp+38h] 
00000093  mov         rax,qword ptr [rsp+38h] 
00000098  call        qword ptr [rax] 

Я попробовал ваш тест и на моей машине, в определенном контексте, результат на самом деле наоборот.

Я запускаю Windows 7 x64, и я создал проект консольного приложения Visual Studio 2010, в который я скопировал ваш код. Если скомпилировать проект в отладки режим и с целью платформы как x86 вывод будет следующий:

прямой вызов: 48.38
Через интерфейсы: 42.43

на самом деле каждый раз при запуске приложения он будет предоставлять немного разные результаты, но вызовы интерфейса всегда будут быстрее. Я предполагаю, что поскольку приложение скомпилировано как x86, оно будет запускаться ОС через WOW.

для полной справки ниже приведены результаты для остальной части конфигурации компиляции и целевых комбинаций.

релиз режим и x86 цель
Прямой вызов: 23.02
Через интерфейс: 32.73

Debug режим и x64 цель
Прямой вызов: 49.49
Через интерфейс: 56.97

релиз режим и x64 цель
Прямой вызов: 19.60
Через интерфейс: 26.45

все вышеперечисленные тесты были выполнены с .Net 4.0 в качестве целевой платформы для компилятора. При переключении на 3.5 и повторении вышеуказанных тестов, вызовы через интерфейс всегда был длиннее, чем прямые вызовы.

Итак, приведенные выше тесты довольно усложняют ситуацию, поскольку кажется, что поведение, которое вы заметили, не всегда происходит.

В конце концов, с риском расстроить вас, я хотел бы добавить несколько мыслей. Многие люди добавили комментарии, что различия в производительности довольно малы и в реальном мире программирования вы не должны заботиться о них, и я согласен с этой точкой зрения. Есть две основные причины оно.

первым и наиболее рекламируемым является то, что .Net был построен на более высоком уровне, чтобы разработчики могли сосредоточиться на более высоких уровнях приложений. Вызов базы данных или внешней службы в тысячи, а иногда и в миллионы раз медленнее, чем вызов виртуального метода. Имея хорошую архитектуру высокого уровня и фокусируясь на большой производительности потребителей всегда принесет лучшие результаты в современных приложениях, а не избежать двойной указатель разыменовывает.

второй и более неясный заключается в том, что команда .Net, построив фреймворк на более высоком уровне, фактически представила ряд уровней абстракции, которые компилятор just in time сможет использовать для оптимизации на разных платформах. Чем больше доступа они дадут нижним слоям, тем больше разработчики смогут оптимизировать для конкретной платформы, но тем меньше компилятор времени выполнения сможет сделать для других. То есть по крайней мере, теория, и именно поэтому все не так хорошо документировано, как в C++ в отношении этого конкретного вопроса.

Я думаю, что чистый случай виртуальной функции может использовать простую таблицу виртуальных функций, как и любой производный класс Foo реализация Bar просто изменил бы указатель виртуальной функции на Bar.

С другой стороны, вызов функции интерфейса IFoo:Bar не мог выполнить поиск в чем-то вроде IFooвиртуальная таблица функций, потому что каждая реализация IFoo не нужно обязательно реализовывать другие функции или интерфейсы, которые Foo делает. Так позиция входа в таблицу виртуальных функций для Bar С другой class Fubar: IFoo не должно совпадать с позицией входа в виртуальную таблицу функций Bar in class Foo:IFoo.

общее правило: занятия проходят быстро. Интерфейсы работают медленно.

Это одна из причин рекомендации "построения иерархий классов и использование интерфейсов внутри иерархии поведения".

для виртуальных методов, разница может быть небольшой (например, 10%). Но для невиртуальных методов и полей разница огромна. Рассмотрим эту программу.

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace InterfaceFieldConsoleApplication
{
    class Program
    {
        public abstract class A
        {
            public int Counter;
        }

        public interface IA
        {
            int Counter { get; set; }
        }

        public class B : A, IA
        {
            public new int Counter { get { return base.Counter; } set { base.Counter = value; } }
        }

        static void Main(string[] args)
        {
            var b = new B();
            A a = b;
            IA ia = b;
            const long LoopCount = (int) (100*10e6);
            var stopWatch = new Stopwatch();
            stopWatch.Start();
            for (int i = 0; i < LoopCount; i++)
                a.Counter = i;
            stopWatch.Stop();
            Console.WriteLine("a.Counter: {0}", stopWatch.ElapsedMilliseconds);
            stopWatch.Reset();
            stopWatch.Start();
            for (int i = 0; i < LoopCount; i++)
                ia.Counter = i;
            stopWatch.Stop();
            Console.WriteLine("ia.Counter: {0}", stopWatch.ElapsedMilliseconds);
            Console.ReadKey();
        }
    }
}

выход:

a.Counter: 1560
ia.Counter: 4587