Зачем вообще использовать модификатор параметра «in» в C #?

Итак, я (думаю, я) понимаю, что inделает модификатор параметра. Но то, что он делает, кажется совершенно избыточным.

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

Есть ли какое-то преимущество в производительности? Я считал, что на внутренней стороне вещей refпараметр должен как минимум копировать физический адрес переменной, который должен быть того же размера, что и любая типичная ссылка на объект.

Итак, тогда преимущество только в более крупных структурах, или есть некоторая закулисная оптимизация компилятора, которая делает его привлекательным в другом месте? В последнем случае почему бы мне не сделать каждый параметр значением in?

in недавно был представлен язык C #.

inна самом деле ref readonly. Вообще говоря, есть только один вариант использования, который inможет быть полезен: высокопроизводительные приложения, работающие с большим количеством больших readonly structs.

Если у вас есть:

readonly struct VeryLarge
{
    public readonly long Value1;   
    public readonly long Value2;

    public long Compute() { }
    // etc
}

и

void Process(in VeryLarge value) { }

В этом случае VeryLargeструктура будет передана по ссылке без создания защитных копий при использовании этой структуры в Processметоде (например, при вызове value.Compute()), а неизменяемость структуры обеспечивается компилятором.

Обратите внимание, что передача not-readonly structс inмодификатором заставит компилятор создать защитную копию при вызове методов структуры и доступе к свойствам в Processметоде выше, что отрицательно скажется на производительности!

Есть действительно хорошая запись в блоге MSDN, которую я рекомендую внимательно прочитать.

Если вы хотите получить больше исторической справки о inвведении, вы можете прочитать это обсуждение в репозитории GitHub языка C #.

В целом, большинство разработчиков согласны с тем, что внедрение inможет рассматриваться как ошибка. Это довольно экзотическая языковая функция, которая может быть полезна только в высокопроизводительных случаях.

передача по inссылке кажется логически эквивалентной передаче по значению.

Верный.

Есть ли какое-то преимущество в производительности?

Да.

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

Не существует требования, чтобы ссылка на объект и ссылка на переменную были одинакового размера, и не требуется, чтобы любой из них был размером машинного слова, но да, на практике оба 32 бита на 32 битовые машины и 64-битные на 64-битных машинах.

Как вы думаете, какое отношение к этому имеет "физический адрес", мне неясно. В Windows мы используем виртуальные адреса , а не физические адреса в коде пользовательского режима. Мне любопытно знать, при каких возможных обстоятельствах вы можете представить, что физический адрес имеет значение в программе на C #.

Также не требуется, чтобы какая-либо ссылка была реализована как виртуальный адрес хранилища. Ссылки могут быть непрозрачными дескрипторами таблиц GC в соответствующей реализации спецификации CLI.

преимущество только в более крупных структурах?

Снижение стоимости передачи больших структур - мотивирующий сценарий для этой функции.

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

есть ли какая-то закулисная оптимизация компилятора, которая делает его привлекательным в других местах?

Компилятору и среде выполнения разрешается производить любую оптимизацию по своему усмотрению, если это не нарушает правил спецификации C #. Насколько мне известно, такой оптимизации для inпараметров еще нет , но это не исключает такой оптимизации в будущем.

почему бы мне не сделать каждый параметр входным?

Что ж, предположим, вы создали intпараметр вместо in intпараметра. Какие накладные расходы?

• для сайта вызова теперь требуется переменная, а не значение
• переменная не может быть зарегистрирована. Тщательно настроенная схема распределения регистров джиттера только что была добавлена ​​в нее.
• код на сайте вызова больше, потому что он должен принимать ссылку на переменную и помещать ее в стек, тогда как раньше он мог просто поместить значение в стек вызовов
• Более крупный код означает, что некоторые инструкции короткого перехода теперь могли стать инструкциями длинного перехода, поэтому, опять же, код теперь больше. Это накладывает отпечаток на самые разные вещи. Кеши заполняются быстрее, дрожание требует больше работы, дрожание может не выполнять определенные оптимизации для больших размеров кода и так далее.
• на вызываемом сайте мы превратили доступ к значению в стеке (или регистре) в косвенное обращение к указателю. Теперь этот указатель, скорее всего, находится в кеше, но все же мы превратили доступ с одной инструкцией к значению в доступ с двумя инструкциями.
• И так далее.

Предположим, это a, doubleи вы измените его на in double. Опять же, теперь переменная не может быть зарегистрирована в высокопроизводительном регистре с плавающей запятой. Это не только влияет на производительность , но и может изменить поведение программы! C # разрешено выполнять арифметические операции с плавающей запятой с точностью выше 64-битной и обычно делает это только в том случае, если числа с плавающей запятой можно зарегистрировать.

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

Есть. При пропускании struct, то inключевое слово позволяет оптимизировать , где компилятор нужно только передать указатель, без риска метода изменения содержания. Последнее критично - это позволяет избежать операции копирования. Для больших структур это может иметь огромное значение.

Это сделано из-за подхода функционального программирования. Один из основных принципов заключается в том, что функция не должна иметь побочных эффектов, что означает, что она не должна изменять значения параметров и должна возвращать какое-то значение. В C # не было возможности передавать структуры (и тип значения) без копирования только по ссылке, что позволяет изменять значение. В swift есть хакерский алгоритм, который копирует структуры (их коллекции - это структуры BTW), пока метод начинает изменять свои значения. Люди, которые используют swift, не все знают о копиях. Это хорошая функция C #, так как она эффективно использует память и явно. Если вы посмотрите на что новоговы увидите, что все больше и больше делается вокруг структур и массивов в стеке. И для этих функций in statement просто необходимо. В других ответах упоминаются ограничения, но это не так важно для понимания того, куда движется .net.

в нем ссылка только для чтения в С # 7.2

это означает, что вы не передаете весь объект в стек функций, как и в случае ref, вы передаете только ссылку на структуру

но попытка изменить значение объекта дает ошибку компилятора.

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