.net performance - Действительно ли опечатанные классы действительно предлагают преимущества?




optimization c# (10)

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

Я проверил несколько тестов, чтобы проверить разницу в производительности и не нашел их. Я делаю что-то неправильно? Я пропустил случай, когда запечатанные классы дадут лучшие результаты?

Кто-нибудь запускал тесты и видел разницу?

Помогите мне учиться :)


Answers

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

Существуют сложные правила относительно типа вызова, виртуальные / невиртуальные, и я не знаю их всех, поэтому я не могу их очертить, но если вы Google для закрытых классов и виртуальных методов, вы можете найти некоторые статьи по этой теме.

Обратите внимание, что любой вид производительности, который вы получили от этого уровня оптимизации, следует рассматривать как последний, всегда оптимизируя алгоритмический уровень до того, как вы оптимизируете уровень кода.

Вот одна ссылка, в которой упоминается следующее: Рамблинг по запечатанному ключевому слову


<Вне темы-декламация>

Я ненавижу запечатанные классы. Даже если преимущества производительности поражают (что я сомневаюсь), они разрушают объектно-ориентированную модель, предотвращая повторное использование через наследование. Например, класс Thread герметизирован. Хотя я вижу, что возможно, что потоки будут максимально эффективными, я также могу представить сценарии, в которых возможность подкласса Thread будет иметь большие преимущества. Авторы классов, если вы должны запечатать свои классы по причинам «производительности», пожалуйста, предоставьте интерфейс, по крайней мере, чтобы нам не пришлось обертывать и заменять везде, где нам нужна функция, которую вы забыли.

Пример: SafeThread должен был обернуть класс Thread, потому что Thread запечатан и нет интерфейса IThread; SafeThread автоматически останавливает необработанные исключения в потоках, что полностью отсутствует в классе Thread. [и нет, необработанные события исключения не собирают необработанные исключения во вторичных потоках].

</ Офф-тема-декламация>


@Vaibhav, какие тесты вы выполнили для измерения производительности?

Я думаю, что нужно было бы использовать Rotor и сверлить в CLI и понять, как запечатанный класс улучшит производительность.

SSCLI (ротор)
SSCLI: общая инфраструктура общего языка

Инфраструктура Common Language (CLI) - это стандарт ECMA, который описывает ядро ​​.NET Framework. CLI общего доступа (SSCLI), также известный как Rotor, представляет собой сжатый архив исходного кода для рабочей реализации CLI ECMA и спецификации языка ECMA C #, технологий, лежащих в основе архитектуры Microsoft .NET.


Ответ: нет, запечатанные классы не работают лучше, чем без запечатывания.

Проблема сводится к callvirt против кодов callvirt IL op. Call быстрее, чем callvirt , а callvirt в основном используется, когда вы не знаете, был ли объект подклассом. Таким образом, люди предполагают, что если вы запечатаете класс, все коды op будут меняться от calvirts до calls и будут быстрее.

К сожалению, callvirt делает другие вещи, которые делают его полезным, например, проверка нулевых ссылок. Это означает, что даже если класс запечатан, ссылка может по-прежнему быть нулевой, и, таким образом, требуется callvirt . Вы можете обойти это (без необходимости запечатывать класс), но это становится немного бессмысленным.

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

См. Этот вопрос для получения дополнительной информации:

Звоните и звоните


Запустите этот код, и вы увидите, что закрытые классы в 2 раза быстрее:

class Program
{
    static void Main(string[] args)
    {
        Console.ReadLine();

        var watch = new Stopwatch();
        watch.Start();
        for (int i = 0; i < 10000000; i++)
        {
            new SealedClass().GetName();
        }
        watch.Stop();
        Console.WriteLine("Sealed class : {0}", watch.Elapsed.ToString());

        watch.Start();
        for (int i = 0; i < 10000000; i++)
        {
            new NonSealedClass().GetName();
        }
        watch.Stop();
        Console.WriteLine("NonSealed class : {0}", watch.Elapsed.ToString());

        Console.ReadKey();
    }
}

sealed class SealedClass
{
    public string GetName()
    {
        return "SealedClass";
    }
}

class NonSealedClass
{
    public string GetName()
    {
        return "NonSealedClass";
    }
}

output: Sealed class: 00: 00: 00.1897568 Класс NonSealed: 00: 00: 00.3826678


Обновление. Начиная с .NET Core 2.0 и .NET Desktop 4.7.1, CLR теперь поддерживает девиртуализацию. Он может принимать методы в закрытых классах и заменять виртуальные вызовы прямыми вызовами - и он также может делать это для незапечатанных классов, если он может понять, что это безопасно.

В таком случае (закрытый класс, который CLR не может обнаружить иначе как безопасный для devirtualise), запечатанный класс должен фактически предлагать какое-то преимущество в производительности.

Тем не менее, я бы не подумал, что стоит подумать, если бы вы уже не профилировали код и не определили, что вы были особенно горячим путем, называемым миллионы раз, или что-то вроде этого:

https://blogs.msdn.microsoft.com/dotnet/2017/06/29/performance-improvements-in-ryujit-in-net-core-and-net-framework/

Оригинальный ответ:

Я выполнил следующую тестовую программу, а затем декомпилировал ее с помощью Reflector, чтобы узнать, какой код MSIL был испущен.

public class NormalClass {
    public void WriteIt(string x) {
        Console.WriteLine("NormalClass");
        Console.WriteLine(x);
    }
}

public sealed class SealedClass {
    public void WriteIt(string x) {
        Console.WriteLine("SealedClass");
        Console.WriteLine(x);
    }
}

public static void CallNormal() {
    var n = new NormalClass();
    n.WriteIt("a string");
}

public static void CallSealed() {
    var n = new SealedClass();
    n.WriteIt("a string");
}

Во всех случаях компилятор C # (Visual Studio 2010 в конфигурации сборки Release) генерирует идентичный MSIL, который выглядит следующим образом:

L_0000: newobj instance void <NormalClass or SealedClass>::.ctor()
L_0005: stloc.0 
L_0006: ldloc.0 
L_0007: ldstr "a string"
L_000c: callvirt instance void <NormalClass or SealedClass>::WriteIt(string)
L_0011: ret 

Часто цитированная причина, по которой люди говорят, что это запечатанные, обеспечивает преимущества производительности, заключается в том, что компилятор знает, что класс не переоценивается, и поэтому может использовать call вместо callvirt поскольку он не должен проверять наличие виртуальных машин и т. Д. Как показано выше, это неправда.

Моя следующая мысль заключалась в том, что, хотя MSIL идентичен, возможно, JIT-компилятор рассматривает закрытые классы по-разному?

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

//            var n = new NormalClass();
00000000  push        ebp 
00000001  mov         ebp,esp 
00000003  sub         esp,8 
00000006  cmp         dword ptr ds:[00585314h],0 
0000000d  je          00000014 
0000000f  call        70032C33 
00000014  xor         edx,edx 
00000016  mov         dword ptr [ebp-4],edx 
00000019  mov         ecx,588230h 
0000001e  call        FFEEEBC0 
00000023  mov         dword ptr [ebp-8],eax 
00000026  mov         ecx,dword ptr [ebp-8] 
00000029  call        dword ptr ds:[00588260h] 
0000002f  mov         eax,dword ptr [ebp-8] 
00000032  mov         dword ptr [ebp-4],eax 
//            n.WriteIt("a string");
00000035  mov         edx,dword ptr ds:[033220DCh] 
0000003b  mov         ecx,dword ptr [ebp-4] 
0000003e  cmp         dword ptr [ecx],ecx 
00000040  call        dword ptr ds:[0058827Ch] 
//        }
00000046  nop 
00000047  mov         esp,ebp 
00000049  pop         ebp 
0000004a  ret 

Я тогда подумал, что, возможно, работает под отладчиком, заставляет его выполнять менее агрессивную оптимизацию?

Затем я запустил автономный исполняемый файл сборки вне любых сред для отладки и использовал WinDBG + SOS для взлома после завершения программы и просмотрел разборку скомпилированного x86-кода JIT.

Как видно из приведенного ниже кода, при работе за пределами отладчика JIT-компилятор более агрессивен, и он ввел метод WriteIt прямо в вызывающий. Однако важно то, что он был идентичным при вызове закрытого или незапечатанного класса. Между закрытым или незапечатанным классом нет никакой разницы.

Здесь при вызове обычного класса:

Normal JIT generated code
Begin 003c00b0, size 39
003c00b0 55              push    ebp
003c00b1 8bec            mov     ebp,esp
003c00b3 b994391800      mov     ecx,183994h (MT: ScratchConsoleApplicationFX4.NormalClass)
003c00b8 e8631fdbff      call    00172020 (JitHelp: CORINFO_HELP_NEWSFAST)
003c00bd e80e70106f      call    mscorlib_ni+0x2570d0 (6f4c70d0) (System.Console.get_Out(), mdToken: 060008fd)
003c00c2 8bc8            mov     ecx,eax
003c00c4 8b1530203003    mov     edx,dword ptr ds:[3302030h] ("NormalClass")
003c00ca 8b01            mov     eax,dword ptr [ecx]
003c00cc 8b403c          mov     eax,dword ptr [eax+3Ch]
003c00cf ff5010          call    dword ptr [eax+10h]
003c00d2 e8f96f106f      call    mscorlib_ni+0x2570d0 (6f4c70d0) (System.Console.get_Out(), mdToken: 060008fd)
003c00d7 8bc8            mov     ecx,eax
003c00d9 8b1534203003    mov     edx,dword ptr ds:[3302034h] ("a string")
003c00df 8b01            mov     eax,dword ptr [ecx]
003c00e1 8b403c          mov     eax,dword ptr [eax+3Ch]
003c00e4 ff5010          call    dword ptr [eax+10h]
003c00e7 5d              pop     ebp
003c00e8 c3              ret

Vs запечатанный класс:

Normal JIT generated code
Begin 003c0100, size 39
003c0100 55              push    ebp
003c0101 8bec            mov     ebp,esp
003c0103 b90c3a1800      mov     ecx,183A0Ch (MT: ScratchConsoleApplicationFX4.SealedClass)
003c0108 e8131fdbff      call    00172020 (JitHelp: CORINFO_HELP_NEWSFAST)
003c010d e8be6f106f      call    mscorlib_ni+0x2570d0 (6f4c70d0) (System.Console.get_Out(), mdToken: 060008fd)
003c0112 8bc8            mov     ecx,eax
003c0114 8b1538203003    mov     edx,dword ptr ds:[3302038h] ("SealedClass")
003c011a 8b01            mov     eax,dword ptr [ecx]
003c011c 8b403c          mov     eax,dword ptr [eax+3Ch]
003c011f ff5010          call    dword ptr [eax+10h]
003c0122 e8a96f106f      call    mscorlib_ni+0x2570d0 (6f4c70d0) (System.Console.get_Out(), mdToken: 060008fd)
003c0127 8bc8            mov     ecx,eax
003c0129 8b1534203003    mov     edx,dword ptr ds:[3302034h] ("a string")
003c012f 8b01            mov     eax,dword ptr [ecx]
003c0131 8b403c          mov     eax,dword ptr [eax+3Ch]
003c0134 ff5010          call    dword ptr [eax+10h]
003c0137 5d              pop     ebp
003c0138 c3              ret

Для меня это обеспечивает надежное доказательство того, что не может быть никакого улучшения производительности между вызывающими методами на запечатанных и незапечатанных классах ... Я думаю, что я счастлив сейчас :-)


Запечатанные классы должны обеспечивать повышение производительности. Поскольку закрытый класс не может быть получен, любые виртуальные члены могут быть превращены в не виртуальных членов.

Конечно, мы говорим о действительно небольшой прибыли. Я бы не стал отмечать класс как запечатанный, чтобы добиться улучшения производительности, если профилирование не показало, что это проблема.


Маркировка класса, sealed должна влиять на производительность.

Бывают случаи, когда csc может call код операции callvirt код call . Однако, похоже, эти случаи встречаются редко.

И мне кажется, что JIT должен иметь возможность выпустить тот же не виртуальный вызов функции для callvirt что и для call , если он знает, что класс не имеет каких-либо подклассов (пока). Если существует только одна реализация метода, нет смысла загружать свой адрес из таблицы vtable - просто вызовите одну реализацию напрямую. В этом случае JIT может даже встроить функцию.

Это немного азартная игра на стороне JIT, потому что, если подкласс будет загружен позже, JIT придется выбросить этот машинный код и снова скомпилировать код, испустив реальный виртуальный вызов. Я предполагаю, что это не случается часто на практике.

(И да, дизайнеры VM действительно агрессивно преследуют эти крошечные победы в производительности).


Я считаю «запечатанные» классы нормальным, и у меня всегда есть причина, чтобы опустить «запечатанное» ключевое слово.

Для меня важными причинами являются:

a) Лучшая проверка времени компиляции (приведение в неработающие интерфейсы будет обнаружено во время компиляции не только во время выполнения)

и, главная причина:

б) Злоупотребление моими классами невозможно таким образом

Я бы хотел, чтобы Microsoft сделала «запечатанный» стандарт, а не «незапечатанным».


Невозможно сказать. Это зависит от того, как выглядит код. Если мы можем предположить, что код уже существует, мы можем просто взглянуть на него и выяснить, как его оптимизировать.

Лучшая локализация кеша, разворачивание цикла, попытка устранить длинные сети зависимостей, чтобы получить лучший параллелизм на уровне инструкций. Предпочитайте условные перемещения по веткам, когда это возможно. При необходимости используйте SIMD-инструкции.

Понимайте, что делает ваш код, и понимайте, на каком оборудовании он работает. Тогда становится довольно просто определить, что вам нужно сделать, чтобы повысить производительность вашего кода. Это действительно единственный поистине общий совет, о котором я могу думать.

Ну, и «Покажите код на SO и попросите совета по оптимизации для этой конкретной части кода».





.net optimization frameworks performance