¿Importa la longitud del nombre variable para el rendimiento C#?

Question

Me he estado preguntando si el uso de nombres largos de variables descriptivas en WinForms C# es importante para el rendimiento. Estoy haciendo esta pregunta ya que en AutoIt v3 (lenguaje interpretado) se mencionó que tener variables con nombres cortos como aa en lugar de veryLongVariableName es mucho más rápido (cuando el programa es más grande que 5 delineador). Me pregunto si es lo mismo en C#?

Answer 1

No, no lo hace. El compilador en realidad no guarda los nombres de las variables originales; puede ver el código IL de cualquier ensamblado compilado con desensamblador.

Answer 2

No, no creo que esa variable larga tenga ningún impacto en el rendimiento de ejecución de una aplicación .NET. AFAIK, el código intermedio (en MSIL) en un ensamblado .NET se traduce al lenguaje de máquina antes de que se ejecute. Aquí es donde los nombres de las variables definitivamente se "descartarán" (si no han sucedido antes) y se reemplazarán por direcciones de memoria simples.

Answer 3

No importa. Aunque puede obtener los nombres al descompilar (ver otros mensajes para más detalles), la instrucción IL no usa esos nombres Leyendo o escribiendo en variables/campos. Las variables y los campos se identifican a través de una construcción diferente. En el espacio de nombre reflection.emit estos son representados por LocalBuilder (para una variable local o FieldBuild para campos) y para enfatizar aún más el punto: ni siquiera necesitan ser nombrados explícitamente.

Answer 4

Es una diferencia clave entre un compilador y un intérprete. Un intérprete realiza una búsqueda de nombre de identificador mientras interpreta el código. Si la búsqueda del nombre ocurre dentro de un bucle que se ejecuta muchas veces, el tiempo necesario para esa búsqueda puede ser importante. Nombres más largos requieren más tiempo.

El compilador C# elimina los nombres de los identificadores en dos etapas distintas. Los nombres de las variables locales se borran y reemplazan por compensaciones de cuadros de pila cuando compila el código fuente a IL. Namespace y nombres de tipos todavía están presentes en el ensamblado. El compilador JIT borra esos, reemplazándolos con los desplazamientos de código para los métodos y los desplazamientos de datos para los campos. La longitud de los nombres de los identificadores no importa aquí, la búsqueda solo ocurre una vez.

Eliminar el gasto de la búsqueda de nombre en un intérprete no es difícil por cierto. Un intérprete decente tokeniza el código fuente, esencialmente un paso previo a la compilación para hacer que el intérprete sea más eficiente. Tal intérprete tampoco tendría un problema de ralentización con los nombres largos de los identificadores.

Answer 5

No, una vez compilados, los nombres de las variables originales ya no se utilizan. El tamaño de los nombres de las variables debería tener un efecto muy pequeño en el tiempo de compilación, pero no en el tiempo de ejecución.

Los idiomas interpretados se ven afectados un poco por los nombres largos de variable. Los nombres largos son más para leer, almacenar y buscar cada vez que se ejecutan, pero el efecto debe ser muy pequeño. La latencia en la lectura/escritura en un disco o incluso en la pantalla debería exceder el retraso causado por nombres de variables más largos.

Si el problema es el tiempo de ejecución, es probable que más algoritmos eficientes en la ejecución proporcionen rendimientos mucho mayores que el acortamiento de nombres de variables. Si la presión de la memoria es el problema, es probable que los algoritmos de memoria ahorren mucho más que acortar los nombres de las variables. Si la solución es algorítmicamente tan estrecha como puede ser, es hora de un nuevo idioma.

Hay algunos absolutos en la programación, pero me siento seguro al decir que acortar los nombres de las variables en el código fuente por razones de rendimiento es ABSOLUTAMENTE la decisión equivocada CADA vez.

Answer 6

Creo que la pregunta sobre la longitud del nombre es real solo para los proyectos Script# (en el caso de la traducción de C# a JavaScript).