¿Por qué se usaría el modificador de parámetro "in" en C #?

Entonces, (creo que) entiendo lo que hace el inmodificador de parámetro. Pero lo que hace parece ser bastante redundante.

Por lo general, creo que la única razón para usar un refsería modificar la variable de llamada, que está explícitamente prohibida por in. Entonces, pasar por inreferencia parece lógicamente equivalente a pasar por valor.

¿Existe algún tipo de ventaja en el rendimiento? Yo creía que en el lado del back-end de las cosas, un refparámetro debe al menos copiar la dirección física de la variable, que debe ser del mismo tamaño que cualquier referencia de objeto típica.

Entonces, ¿la ventaja es solo en estructuras más grandes, o hay alguna optimización del compilador detrás de escena que lo hace atractivo en otros lugares? Si es lo último, ¿por qué no debería hacer que cada parámetro sea an in?

in se introdujo recientemente en el lenguaje C #.

ines en realidad un ref readonly. En términos generales, solo hay un caso de uso en el que inpuede ser útil: las aplicaciones de alto rendimiento que se ocupan de muchos correos electrónicos grandes readonly struct.

Asumiendo que tienes:

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

    public long Compute() { }
    // etc
}

y

void Process(in VeryLarge value) { }

En ese caso, la VeryLargeestructura se pasará por referencia sin crear copias defensivas cuando se utilice esta estructura en el Processmétodo (por ejemplo, al llamar value.Compute()), y el compilador asegura la inmutabilidad de la estructura.

Tenga en cuenta que pasar un not-readonly structcon un inmodificador hará que el compilador cree una copia defensiva cuando llame a los métodos de struct y acceda a las propiedades en el Processmétodo anterior, lo que afectará negativamente el rendimiento.

Hay una entrada de blog de MSDN realmente buena que recomiendo leer con atención.

Si desea obtener más antecedentes históricos de la inintroducción, puede leer esta discusión en el repositorio de GitHub del lenguaje C #.

En general, la mayoría de los desarrolladores están de acuerdo en que la introducción de inpodría verse como un error. Es una característica de lenguaje bastante exótica y solo puede ser útil en casos de borde de alto rendimiento.

pasar por inreferencia parece lógicamente equivalente a pasar por valor.

Correcto.

¿Existe algún tipo de ventaja en el rendimiento?

Si.

Yo creía que en el lado del back-end de las cosas, un refparámetro debe al menos copiar la dirección física de la variable, que debe ser del mismo tamaño que cualquier referencia de objeto típica.

No existe el requisito de que una referencia a un objeto y una referencia a una variable sean del mismo tamaño, y no existe el requisito de que ninguna sea del tamaño de una palabra de máquina, pero sí, en la práctica ambas son de 32 bits en 32 máquinas de bits y 64 bits en máquinas de 64 bits.

No tengo claro qué crees que tiene que ver la "dirección física" con esto. En Windows usamos direcciones virtuales , no direcciones físicas en el código de modo de usuario. Tengo curiosidad por saber en qué posibles circunstancias imagina que una dirección física es significativa en un programa de C #.

Tampoco es un requisito que se implemente una referencia de ningún tipo como la dirección virtual del almacenamiento. Las referencias pueden ser identificadores opacos en tablas GC en una implementación conforme a la especificación CLI.

¿La ventaja es solo en estructuras más grandes?

Disminuir el costo de pasar estructuras más grandes es el escenario motivador para la función.

Tenga en cuenta que no hay garantía de que inun programa sea realmente más rápido y puede hacer que los programas sean más lentos. Todas las preguntas sobre desempeño deben ser respondidas mediante investigación empírica . Hay muy pocas optimizaciones que siempre sean ganadoras ; esta no es una optimización de "siempre ganar".

¿Hay alguna optimización del compilador detrás de escena que lo haga atractivo en otros lugares?

El compilador y el tiempo de ejecución pueden realizar cualquier optimización que elijan si hacerlo no infringe las reglas de la especificación C #. Que yo sepa, todavía no existe tal optimización para los inparámetros, pero eso no excluye tales optimizaciones en el futuro.

¿Por qué no debería hacer que todos los parámetros estén incluidos?

Bueno, suponga que crea un intparámetro en lugar de un in intparámetro. ¿Qué costos se imponen?

• el sitio de la llamada ahora requiere una variable en lugar de un valor
• la variable no se puede registrar. El esquema de asignación de registros cuidadosamente ajustado del jitter acaba de recibir una llave inglesa.
• el código en el sitio de la llamada es más grande porque debe tomar una referencia a la variable y ponerla en la pila, mientras que antes simplemente podía empujar el valor a la pila de llamadas
• un código más grande significa que algunas instrucciones de salto corto pueden haberse convertido ahora en instrucciones de salto largo, por lo que, nuevamente, el código ahora es más grande. Esto tiene efectos colaterales en todo tipo de cosas. Los cachés se llenan antes, el jitter tiene más trabajo que hacer, el jitter puede optar por no realizar ciertas optimizaciones en códigos de mayor tamaño, etc.
• en el sitio del destinatario, hemos convertido el acceso a un valor en la pila (o registro) en una indirección en un puntero. Ahora, es muy probable que ese puntero esté en la caché, pero aún así, ahora hemos convertido un acceso de una instrucción al valor en un acceso de dos instrucciones.
• Y así.

Suponga que es un doubley lo cambia a un in double. Nuevamente, ahora la variable no se puede registrar en un registro de punto flotante de alto rendimiento. Esto no solo tiene implicaciones en el rendimiento , ¡también puede cambiar el comportamiento del programa! A C # se le permite hacer aritmética flotante con una precisión superior a 64 bits y, por lo general, solo lo hace si los flotantes se pueden registrar.

Esta no es una optimización gratuita. Tienes que medir su desempeño contra las alternativas. Su mejor opción es simplemente no hacer estructuras grandes en primer lugar, como sugieren las pautas de diseño.

Ahi esta. Al pasar a struct, la inpalabra clave permite una optimización donde el compilador solo necesita pasar un puntero, sin el riesgo de que el método cambie el contenido. El último es crítico: evita una operación de copia. En estructuras grandes, esto puede marcar una gran diferencia.

Esto se hace debido al enfoque de programación funcional. Uno de los principales principios es que la función no debe tener efectos secundarios, lo que significa que no debe cambiar los valores de los parámetros y debe devolver algún valor. En C # no había forma de pasar estructuras (y tipo de valor) sin ser copiadas solo por referencia, lo que permite cambiar el valor. En swift hay un algoritmo hacky que copia la estructura (sus colecciones son estructuras por cierto) siempre que el método comience a cambiar sus valores. Las personas que usan Swift no son todas conscientes del material de copia. Esta es una buena característica de C # ya que es eficiente en memoria y explícita. Si miras lo nuevoverá que se hacen más y más cosas alrededor de estructuras y matrices en la pila. Y en la declaración solo es necesario para estas características. Hay limitaciones mencionadas en las otras respuestas, pero no es tan esencial para comprender hacia dónde se dirige .net.

en él es referencia de solo lectura en c # 7.2

Esto significa que no pasan todo el objeto de pila función similar a la ref caso se pasa única referencia a la estructura

pero el intento de cambiar el valor del objeto produce un error del compilador.

Y sí, esto le permitirá optimizar el rendimiento del código si usa grandes estructuras.