Сказка про Method as Parameter13.03.2023 10:01

Привет. Меня зовут Саша Денисов, я инженер в Контуре. 

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

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

Вы уже могли видеть одну из мои статей про Guid.NewGuid (). Сегодня расскажу вам сказку про Method as Parameter.

Наверняка вы вызывали методы в C#. И казалось бы, что тут может быть интересного. Но тут есть о чем поговорить, есть что интересного рассказать.

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

Один из распространённых способов использовать методы — передавать их как аргументы. Например, внутрь класса можно передать метод, который будет возвращать настройки этого класса, чтобы динамически настраивать какой-нибудь уровень параллелизма. Или легко вспоминается LINQ, где в аргументы .Select() вы передаёте какой-нибудь selector.

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

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

Начнем с простого и искусственного

Выдумаем, для начала, искусственный пример. Для простоты. Потом обязательно посмотрим на более реальные примеры.

Что-нибудь очень простое. Допустим, у нас есть очень много пар чисел. И мы хотим их складывать. Но бывает так, что складывать числа надо по-разному. И мы хотим дать пользователю определять функцию сложения. Поэтому мы написали такую реализацию:

private int CallAdd(Func userAdditionFunction, int arg1, int arg2)
{
    return userAdditionFunction(arg1, arg2);
}

Очевидно, в таком виде метод CallAdd бесполезен.

Но иногда мы не хотим пользоваться той реализацией метода, которую передал пользователь. А хотим пользоваться своей собственной AdditionFunction, в зависимости от настройки UseCustomFunction. Вот мы её рядом и реализовали:

private int DefaultAdditionFunction(int x, int y)
{
    return x + y;
}

И вот такой у нас получился код основной работы (да, мы тут ничего не делаем с результатом, но это же искусственный пример):

private readonly Func userFunction; //initialized in constructor
 
public void DoJob()
{
    for (int i = 0; i < pairsOfNumbersCount; i++)
    {
        if (UseCustomFunction)
            CallAdd(userFunction, i, i);
        else
            CallAdd(DefaultAdditionFunction, i, i);
    }
}

И вдруг, вы замечаете, что в случаях, когда UseCustomFunction = false (то есть, когда мы начинаем пользоваться нашей собственной реализацией DefaultAdditionFunction), ваше приложение начинает работать медленнее, потребляет больше CPU и погрязает в GC. Даже если код реализации userFunction абсолютно идентичен нашей собственной DefaultAdditionFunction.

Проверяем

Не верите? Давайте забенчмаркаем наш метод DoJob. Чтобы было честно, сделаем так:  private readonly Func userFunction = DefaultAdditionFunction;. То есть вызываемые функции будут абсолютно одинаковы. Ну и пусть pairsOfNumbersCount = 10 тысяч.

Под катом код всего бенчмарка

private const int PairsOfNumbersCount = 10_000;

private Func userFunction;

[Params(true, false)]
public bool UseCustomFunction;

[GlobalSetup]
public void SetUp()
{
    userFunction = DefaultAdditionFunction;
}
 
[Benchmark]
public void DoJob()
{
    for (int i = 0; i < pairsOfNumbersCount; i++)
    {
        if (UseCustomFunction)
            CallAdd(userFunction, i, i);
        else
            CallAdd(DefaultAdditionFunction, i, i);
    }
}
 
private int CallAdd(Func userAdditionFunction, int arg1, int arg2)
{
    return userAdditionFunction(arg1, arg2);
}
 
private int DefaultAdditionFunction(int x, int y)
{
    return x + y;
}

Получим вот какой результат.

Для простоты выделим текстом самое важное:

| Method | UseCustomFunction |     Mean |     Gen0 | Allocated |
|------- |------------------ |---------:|---------:|----------:|
|  DoJob |             False | 75.83 us | 101.9287 |  640000 B |
|  DoJob |              True | 20.58 us |        - |         - |

Почему-то, когда мы пользуемся нашей собственной реализацией (UseCustomFunction = false), код работает примерно в 3.75 раз медленнее (см. Mean, т.е. среднее время выполнения функции)! И выделяет кучу managed-объектов на хипе, за что мы расплачиваемся сборками мусора (см. Gen 0 — количество сборок мусора, и Allocated — сколько места заняли все выделенные managed-объекты за время работы функции).

Почему так?

Всё, на самом деле, достаточно просто. Метод CallAdd хочет видеть в аргументах объект типа Func. Func — это объект. В случае, когда мы пользуемся локальной переменной userFunction, этот объект уже есть, он был создан, когда выполнилась написанная нами строчка userFunction = DefaultAdditionFunction;, и «лежит» в этой локальной переменной.

Когда же мы передаем в качестве аргумента «наш метод» DefaultAdditionFunction, мы каждый раз на каждой итерации цикла заново создаём экземпляр Func, ссылающийся, очень грубо говоря, на реализацию DefaultAdditionFunction из MethodTable типа нашего класса в привязке к конкретному экземпляру нашего класса.

Возможность просто написать имя какого-то метода в качестве аргумента — это, можно сказать, сахар, предоставленный языком. Который нагло скрыл от нас то, что на самом деле произойдёт. А именно — создание объекта, который от нас на самом деле и хотели.

Это, кстати, можно проследить в листинге IL-кода:

.method public hidebysig instance void  DoJob() cil managed
{
  .custom instance void [BenchmarkDotNet.Annotations]BenchmarkDotNet.Attributes.BenchmarkAttribute::.ctor() = ( 01 00 00 00 ) 
  // Code size       62 (0x3e)
  .maxstack  3
  .locals init (int32 V_0)
  IL_0000:  ldc.i4.0
  IL_0001:  stloc.0
  IL_0002:  br.s       IL_0034
  IL_0004:  ldarg.0
  IL_0005:  ldfld      bool benchmarks.FunctionCall::UseCustomFunction
  IL_000a:  brfalse.s  IL_001c
  IL_000c:  ldarg.0
  IL_000d:  ldfld      class [System.Runtime]System.Func`3 benchmarks.FunctionCall::userFunction
  IL_0012:  ldloc.0
  IL_0013:  ldloc.0
  IL_0014:  call       int32 benchmarks.FunctionCall::CallAdd(class [System.Runtime]System.Func`3,
                                                              int32,
                                                              int32)
  IL_0019:  pop
  IL_001a:  br.s       IL_0030
  IL_001c:  ldnull
  IL_001d:  ldftn      int32 benchmarks.FunctionCall::DefaultAdditionFunction(int32,
                                                                              int32)
  IL_0023:  newobj     instance void class [System.Runtime]System.Func`3::.ctor(object,
                                                                                                   native int)
  IL_0028:  ldloc.0
  IL_0029:  ldloc.0
  IL_002a:  call       int32 benchmarks.FunctionCall::CallAdd(class [System.Runtime]System.Func`3,
                                                              int32,
                                                              int32)
  IL_002f:  pop
  IL_0030:  ldloc.0
  IL_0031:  ldc.i4.1
  IL_0032:  add
  IL_0033:  stloc.0
  IL_0034:  ldloc.0
  IL_0035:  ldarg.0
  IL_0036:  ldfld      int32 benchmarks.FunctionCall::pairsOfNumbersCount
  IL_003b:  blt.s      IL_0004
  IL_003d:  ret
} // end of method FunctionCall::DoJob

Вот, в строке IL 0005 мы берем наш флажок UseCustomFunction. Если он false, прыгаем на адрес IL 001c. Иначе идем дальше. Давайте сравним эти две ветки.

Посмотрим на случай, когда UseCustomFunction = false. В следующей за IL 001c строке, IL 001d, мы извлекаем адрес функции DefaultAdditionFunction из типа FunctionCall (простите, так мерзко назван класс, где размещены все наши методы для эксперимента). А в следующей строке IL 0023 есть четкая инструкция newobj Func3. Это мы создали наш необходимый Func. Это самый настоящий new object();.

Теперь посмотрим на случай, когда UseCustomFunction = true. Мы пойдем дальше, до строки IL_000d, и просто возьмём адрес поля с готовым экземпляром Func3.

Всё, дальше эти методы абсолютно одинаковы. Они вызывают CallAdd с подготовленными аргументами.

Как легко заметить, разница этих двух веток такая: одна ветка (UseCustomFunction = false) берет адрес метода и создаёт объект Func, а другая ветка (UseCustomFunction = true) берет адрес готового объекта из локального поля и больше ничего, что сильно дешевле и не создает объектов на хипе.

А жизненный пример будет?

Да, будет! На самом деле их полно, зачастую мы их даже не замечаем, когда пишем такой код.

Эта сказка основана на реальных событиях.

А из самого простого, но при этом очень распространённого примера из жизни — LINQ. Не зря он упоминался в начале статьи. Каждый наверняка встречал и писал такой код:

collection.Select(DoSmth);

Всё, в этот момент вы воспроизвели проблему с созданием лишних объектов, которую мы сейчас обсуждаем. На каждый вызов Select (к счастью, не на каждый элемент в коллекции, а один раз перед вызовом Select) будет создаваться новый объект Func, с помощью которого и будет вызываться наш метод DoSmth.

Давайте напишем бенчмарк, чтобы было нагляднее:

private Func initializedFuncObject;
private long[] arguments;
 
[GlobalSetup]
public void Setup()
{
    initializedFuncObject = Func;
    arguments = new long[5];
    for (var i = 0; i < arguments.Length; i++)
        arguments[i] = i;
}
 
[Benchmark]
public long Naive()
{
    return arguments.Select(Func).Sum();
}
 
[Benchmark]
public long CachedFunction()
{
    return arguments.Select(initializedFuncObject).Sum();
}
 
public long Func(long x)
{
    return x + 10;
}

Пусть у нас есть коллекция arguments из N = 5 элементов. И мы хотим модифицировать каждый элемент какой-нибудь функцией Func. Возьмём самую тривиальную: будем прибавлять к числу 10. А чтобы ленивый IEnumerable всё-таки отработал, вызовем какую-нибудь агрегирующую функцию,  Sum например.

Сравним эти методы:

Результат интересный. Четко видно, что вариант с CachedFunction аллоцирует меньше объектов (как раз не создаёт этот самый Func), а значит потратит меньше времени и ресурсов на GC. И в целом работает чуточку быстрее наивной реализации (очевидно, чем больше количество элементов N, тем меньше будет заметна разница во времени работы метода;, но легко представить ситуацию, когда, например, N маленькое, зато весь Select вызывают в каком-нибудь внешнем цикле очень часто).

Для тех, кто всё понимает,  и для зануд, как автор этого текста.

Нельзя не воспользоваться случаем и не похейтить LINQ. Очевидно, если мы гонимся за производительностью, LINQ наш враг. Не будем объяснять почему, просто покажем. Кому интересно, покопается сам.

Добавим в бенчмарк метод:

[Benchmark]
public long LinqHater()
{
    var sum = 0L;
    for (var i = 0; i < arguments.Length; i++)
        sum += Func(arguments[i]);
 
    return sum;
}

Вот так-то лучше, сразу стало спокойнее.

Но тут не всё рассказано!

Да, в этой теме (и вообще во всем том, чего мы касались в этом тексте) ещё очень много тонкостей и мелочей, которые хотелось бы показать. Ну например:

• А что, если методы замыкаются на какие-то переменные?

• А как повлияет Inlining\NoInlining методов?

• Что такое бенчмарк, как он работает, как его запустить, как правильно писать бенчмарки?

• А как вообще найти все такие (и при этом обязательно горячие) места в коде, ведь мы эти типы (Func'<>) нигде сами не создаём и не используем, их создаёт компилятор!

• Как смотреть и как правильно читать IL-код?

• Почему компилятор сам не может понять, что можно просто закешировать функцию один раз, и решить за нас эту проблему? (кстати,  занятная ссылка)

• Кто такой этот MethodTable?

• …

И так уже получилось много текста. Может быть в другой раз, когда захочется рассказать очередную сказку. А ещё всегда можно поэкспериментировать и поразбираться самому.

Call to action?

А его не будет. Но теперь вы обладаете ещё одним небольшим знанием, а это уже хорошо. А как им пользоваться, личное дело каждого.

© Habrahabr.ru