Сказка про Method as Parameter

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

private readonly Func<int, int, int> 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<int, int, int> userFunction = DefaultAdditionFunction;. То есть вызываемые функции будут абсолютно одинаковы. Ну и пусть pairsOfNumbersCount = 10 тысяч.

private const int PairsOfNumbersCount = 10_000;

private Func<int, int, int> 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<int, int, int> 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<int, int, int>. Func — это объект. В случае, когда мы пользуемся локальной переменной userFunction, этот объект уже есть, он был создан, когда выполнилась написанная нами строчка userFunction = DefaultAdditionFunction;, и "лежит" в этой локальной переменной.

Когда же мы передаем в качестве аргумента "наш метод" DefaultAdditionFunction, мы каждый раз на каждой итерации цикла заново создаём экземпляр Func<int, int, int>, ссылающийся, очень грубо говоря, на реализацию 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<int32,int32,int32> 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,int32>,
                                                              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<int32,int32,int32>::.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,int32>,
                                                              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<int32,int32,int32>. Это мы создали наш необходимый Func. Это самый настоящий new object();.

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

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

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

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

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

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

collection.Select(DoSmth);

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

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

private Func<long, long> 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;
}

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

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

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

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

• А как повлияет InliningNoInlining методов?

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

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

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

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

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

• …

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

Call to action?

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