Замороченного

Автор: Sinix
Дата: 23.04.16

пока не будет, сорри.

В качестве компенсации, Jack128 напомнил про:

        static int Do(int i, params int[] values)
        {
            return i + 1;
        }

        static int Do2(int i, int[] values)
        {
            return i + 1;
        }

В чём разница между этими двумя методами с точки зрения перфоманса?

Без подсказок, и так слишком быстро угадываете, черти

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

Здравствуйте, Don Reba, Вы писали:

DR>

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

	Подсказка
	А проверьте в свежей студии с таргетингом на 4.6+.

Здравствуйте, Sinix, Вы писали:

	Скрытый текст
	А вот не выкинется ли оно из IL-кода целиком для Release build? Т.е. оба метода будут учитывать лишь первый параметр, т.е. окажутся идентичны.

Здравствуйте, Mr.Delphist, Вы писали:


MD>А вот не выкинется ли оно из IL-кода целиком для Release build? Т.е. оба метода будут учитывать лишь первый параметр, т.е. окажутся идентичны.
Неа, JIT не настолько продвинут в этом плане.

Вот в .Net Native — вполне вероятно. Если ещё не — в следующих релизах точно. Как с инлайном закончат, конечно. Без него половина прочих оптимизация не особо эффективна.

Здравствуйте, Sinix, Вы писали:

S>Замороченного

Автор: Sinix
Дата: 23.04.16

пока не будет, сорри.

S>В качестве компенсации, Jack128 напомнил про:
S>

S>        static int Do(int i, params int[] values)
S>        {
S>            return i + 1;
S>        }

S>        static int Do2(int i, int[] values)
S>        {
S>            return i + 1;
S>        }
S>

S>В чём разница между этими двумя методами с точки зрения перфоманса?

S>Без подсказок, и так слишком быстро угадываете, черти

если вызывать Do не передавая готового массива, то он будет создаваться неявно.
соотв. если много вызывать перфоманс будет деградировать
а если вот так Do(1, null) то думаю никакой разницы

Здравствуйте, ksg71, Вы писали:


K>если вызывать Do не передавая готового массива, то он будет создаваться неявно.

Да ёкылымыны!

Как закинешь какую-нить экзотику, так через час ответят, как вопрос из разряда взять и посмотреть — так до бесконечности тянуться будет.

Подсказка прямым текстом: а если проверить в проекте VS 2015 с таргетингом на 4.6+?

S>Без подсказок, и так слишком быстро угадываете, черти

	Скрытый текст
	Ты не забыл "= null" в сигнатуре Do2()? Я так понимаю это про оптимизацию Array.Empty<T> которую добавили в Roslyn? Тогда оно ещё зависит от разрядности. Как минимум на 64-х разрядной системе если приложение запущено в 32bit, я видел как вызов с Array.Empty<T> по скорости практически равен вызову с new int[0] (одна секунда на лярд итераций). Если то же приложение на той же машине запущено в x64 — то разница становится 10x в пользу оптимизации на Array.Empty.

Здравствуйте, Sinix, Вы писали:

DR>>В первом случае новый массив создаётся при каждом вызове, а во втором можно передать уже созданный.

Так было раньше, теперь для 4.6+ используется Array.Empty<T>()

S>А проверьте в свежей студии с таргетингом на 4.6+.

+1

Здравствуйте, hi_octane, Вы писали:

UPD:
_>Ты не забыл "= null" в сигнатуре Do2()?

Ну я же сказал — без подсказок Так совсем очевидно.

2All: А чойто один я развлекаюсь? подключайтесь

Здравствуйте, Sinix, Вы писали:

MD>>А вот не выкинется ли оно из IL-кода целиком для Release build? Т.е. оба метода будут учитывать лишь первый параметр, т.е. окажутся идентичны.
S>Неа, JIT не настолько продвинут в этом плане.

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

for (var i = 0; i < Count; i++) {
        r += Do1(i);
}

                for (int i = 0; i < Count; i++) {
00007FF85E2A0C8E  lea         esi,[rsi+rdi+1]  
00007FF85E2A0C92  inc         edi  
00007FF85E2A0C94  cmp         edi,989680h  
00007FF85E2A0C9A  jl          00007FF85E2A0C8E

Здравствуйте, rameel, Вы писали:

Не берусь судить, но либо джит осведомлен об Array.Empty<T>, либо он гораздо умней, чем о нем думают Запретил джиту инлайнить метод, и джит вынес вызов Array.Empty за пределы цикла:

00007FF85E290C89  call        00007FF8BDA32B00  
                for (int i = 0; i < Count; i++) {
00007FF85E290C8E  mov         rdx,2A84EB67700h  
00007FF85E290C98  mov         rdx,qword ptr [rdx]  
00007FF85E290C9B  mov         ecx,edi  
                r += Do1(i);
00007FF85E290C9D  call        00007FF85E290078  
00007FF85E290CA2  add         eax,esi  
00007FF85E290CA4  mov         esi,eax  
00007FF85E290CA6  inc         edi  
00007FF85E290CA8  cmp         edi,989680h  
00007FF85E290CAE  jl          00007FF85E290C8E

Здравствуйте, rameel, Вы писали:

R>Не берусь судить, но либо джит осведомлен об Array.Empty<T>, либо он гораздо умней, чем о нем думают Запретил джиту инлайнить метод, и джит вынес вызов Array.Empty за пределы цикла:

Может он атрибутом Pure помечен?

Здравствуйте, rameel, Вы писали:


R>Не берусь судить, но либо джит осведомлен об Array.Empty<T>, либо он гораздо умней, чем о нем думают Запретил джиту инлайнить метод, и джит вынес вызов Array.Empty за пределы цикла:

Оно и раньше было, но работало если повезёт.
Или пример удачный, или эвристики в RyuJit прокачали.

При любом раскладе — мелочь, а приятно

Здравствуйте, AndrewVK, Вы писали:

AVK>Может он атрибутом Pure помечен?

Да, точно. Как-то я пропустил этот момент с Pure-атрибутом. А давно джит умеет с ним работать?

[Pure]
[ReliabilityContract(Consistency.WillNotCorruptState, Cer.MayFail)]
public static T[] Empty<T>()
{
        Contract.Ensures(Contract.Result<T[]>() != null);
        Contract.Ensures(Contract.Result<T[]>().Length == 0);
        Contract.EndContractBlock();

        return EmptyArray<T>.Value;
}

Здравствуйте, rameel, Вы писали:

R>Да, точно. Как-то я пропустил этот момент с Pure-атрибутом. А давно джит умеет с ним работать?

Спроси чего попроще. Просто догадка. Не факт что он вообще его учитывает, а не самостоятельно чистоту детектирует по коду. Надо, короче, экспериментировать.

Здравствуйте, rameel, Вы писали:

R>Здравствуйте, Sinix, Вы писали:

DR>>>В первом случае новый массив создаётся при каждом вызове, а во втором можно передать уже созданный.

Между прочим, это отклонение от спецификации C# и breaking change, о чём я им говорил ещё пару лет назад. Спецификация гарантирует создание нового массива при каждом вызове метода в expanded form. Видимо, они решили, что бенефиты от этой оптимизации перевешивают негативные последствия breaking change (и правильно решили, наверное). Мораль: не нужно в спецификации давать гарантий, которые не являются необходимыми для реализации какой-либо фичи.