Вопрос по оптимизации кода. Какой код будет более оптимальным для C#?

Question

[Роман Кофф]

string[] numbers = new string[] { "3", "2", "5", "1", "4" };
int max = 0;

// вариант 1
for (int i = 0; i < numbers.Length; i++)
{
	if (int.Parse(numbers[i]) > max)
		max = int.Parse(numbers[i]);
}

// вариант 2
for (int i = 0; i < numbers.Length; i++)
{
	int n = int.Parse(numbers[i]);
	if (n > max)
		max = n;
}

Comments

[Петр]

У вас в первом варианте может быть по 2 вызова int.Parse на каждую итерацию.
2*n или 1*n - что эффективнее?

[Роман Кофф]

Петр, Вопрос не про алгоритм, а про оптимизацию компилятора.
Как он обрабатывает подобные конструкции.

Я не очень в этом силен, но могу предположить два варианта:
1. Результат первого вычисления остается в регистре и берется оттуда.
2. Создается переменная, в которую заносится результат функции и потом подставляется.

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

[Петр]

Роман Кофф, "Результат первого вычисления остается в регистре и берется оттуда." а почему он должен это делать?
Ни один оптимизатор кода такое делать не будет. Результат функции может зависеть от времени запуска или выдавать вообще случайное значение, и оптимизатор это не может узнать.

[Алексей Павлов]

Роман Кофф, компилятор не знает, метод чистый, или нет, то есть, будет ли все вызовы вернут ли одинаковый результат, и будет ли делать что-то дополнительное, помимо возврата результата. Поэтому, компилятор так не делает - он всегда выполняет честно указанные команды. Если нужно сделать кэширование, то либо делать его самому, либо использовать какие-либо инструменты (например, MethodCache.Fody).
Некоторые методы (в том числе и int.Parse) отмечены атрибутом [Pure]. Но эти атрибуты используются для контрактов, а не для кэширования результатов.

[freeExec]

Однако компилятор считает, что результат int.Parse не консистентен и вычисляет результат каждый раз заново.

[Роман Кофф]

Вот теперь все встало на место. Спасибо. Нужную инфу получил. Часто в поиске видел похожие примеры (бывало даже на msdn), поэтому и возникли подозрения. В общем мир не перевернулся и все по прежнему ;)

Answer 1

[Илья]

Нужно собрать релизную сборку и сравнить IL код. Вполне возможно что это одно и то же. А если различия и будут, то можно говорить только о конкретной версии dotnet framework. IL может изменяться в зависимости от конкретной CLR или конкретной версии framework. Но даже увидев инструкции я бы не стал предполагать, что из этого быстрее, а написал бенчмарк. Потому что все еще и зависит от железа на котором исполняется.
https://github.com/dotnet/BenchmarkDotNet

PS

Прежде чем заниматься такими микрооптимизациями, нужно понимать, действительно ли это нужно. Если это ради обучения - ок, но если это реальная задача то в 99% случаев узким местом будет не тот код, который вы считаете узким местом. А реальность покажет профилировщик.

Comments

[Роман]

Даже без просмотра il был уверен, что в первом случае 2 вызова будет, ибо il соответствует написанному полностью, оптимизация происходит на уровне jit. Да и как железо влиять то будет на код? Только если варианты на разном железе сравнивать. Даже больше скажу, даже RyuJIT не может это оптимизировать.

[Илья]

Роман,

Да и как железо влиять то будет на код? Только если варианты на разном железе сравнивать.

Да, я это и имел ввиду. На разном железе может по разному исполняться, и не всегда более новый процессор будет быстрее.

[Илья]

Даже без просмотра il был уверен, что в первом случае 2 вызова будет, ибо il соответствует написанному полностью

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

Answer 2

[Роман]

sharplab.io в помощь вам. вариант 2 однозначно оптимальнее, что даже показывает код после JIT. JIT даже не оптимизирует 2 вызов, компилятор бы C или C++ думаю бы оптимизировал до одного вызова Parse, JIT такое не делает, другое, что второй вариант более понятен и читаем.

Comments

[Роман Кофф]

Спасибо за sharplab.io. Ценный ресурс.

Answer 3

[Роман Кофф]

Ок. А если вместо функции стоит выражение? Например a = b * c. Есть про такие варианты какие нибудь правила?

Comments

[Роман]

В этом случае JIT делает оптимизацию.

using System;

public class Program {
    int a=1;
    int b=2;
    int max;   
  
    public void Main1() {
      if (a*b>0)
           max = a*b;
    }
    public void Main2(){
      int n = a*b;
      if (n > 0)
        max = n;
    }
}

ссылочка на sharplab

на уровне IL оптимизации нет, но если включить выход JIT, то код одинаковый. Почему с функцией нет оптимизации, могу сказать почему (мое предположение). Есть такое понятие, чистая функция, это функция которая, при одних и тех же параметрах возвращает одно и тоже значение, чистые функции это удел функциональных языков. Тут же jit не может выяснить, будет один и тот же результат и поэтому вызов будет дважды. Я так думаю компилятор C или C++ вполне могут оптимизировать, но они не на лету работают и могут себе это позволить.