¿La estructura del espacio de nombre o de la carpeta afecta el rendimiento de un ensamblaje?

Question

No puedo evitar preguntarme si los espacios de nombres o la estructura de la carpeta del proyecto afectan el rendimiento del ensamblaje. Mi instinto dice "no, pero posiblemente puede afectar el tiempo de compilación".

Pensar en el rendimiento siempre es un obstáculo, especialmente si eres un novato. No puedo evitarlo! Entonces, pensé en preguntarle a mis compañeros desarrolladores de juegos a quién respeto y admiro.

Answer 1

Todo el mundo ha explicado cómo la optimización prematura es una mala idea (lo que es): sin embargo, explicaré por qué realmente no hace ninguna diferencia (excepto en los casos en los que utiliza la reflexión - más sobre esto más adelante).

referencia estática En Código

El CLR (y por lo tanto MSIL - que es lo que C# compila a) en realidad no tiene ninguna noción o concepto de espacios de nombres. Un tipo (clase, enumeración, etc.) se denomina por su nombre completo (por ejemplo, System.Runtime.Serialization.ISerializable) y las 'paradas completas' son tan opacas (significativas) como cualquier otro carácter en el nombre. El concepto completo de espacios de nombres es algo que C# (o el idioma que esté usando) le brinda a usted. Sin embargo, en términos de MSIL sin procesar, el nombre del tipo tampoco importa.

En MSIL nunca se refiere a algo por su nombre. Todo en un ensamblado (dll o exe) tiene un cierto tipo de mango. Por ejemplo, un tipo tiene un TypeHandle y cualquier elemento contenido por un tipo tiene un MemberHandle: ambos son un entero de 32 bits. Por lo tanto, cuando llama a un método, no escribe call <MethodName> on <TypeName> in <Assembly> en MSIL; en su lugar, escribe call <MethodHandle> on <TypeHandle> in <Assembly>. Por lo tanto, obtener un tipo que tenga 5000 caracteres en su nombre requiere la misma cantidad de tiempo que uno con 5. Los nombres reales se almacenan en un lugar separado en el ensamblaje: solo para que pueda usar el reflejo para obtenerlos, o para compiladores (en otras palabras, los nombres solo se almacenan "para su información"); esto se denomina metadatos.

Creo que hay una manera de hacer que ILDASM te proporcione el MSIL sin procesar, pero no estoy seguro.

acceder mediante Reflexión

Debido a que usted está haciendo una comparación de cadenas entre el nombre del tipo que desee y los nombres disponibles en el montaje se hace una diferencia: las comparaciones de cadenas son una operación O (n). Sin embargo, esta vez es minúsculo en comparación con el costo total de la reflexión y es completamente insignificante (hará nanosegundos de una diferencia) - ni siquiera se preocupe por ello.

Resumen

Esta es la razón por la optimización prematura es realmente malo - usted asumió que era un cuello de botella donde en realidad no hay ninguna rápida o más lenta es la forma de hacerlo.

Answer 2

Respuesta: No, la estructura de la carpeta del proyecto y los espacios de nombres no tendrán un efecto apreciable en el rendimiento.

Una palabra sobre el rendimiento.

Escrito está:

optimización prematura es la raíz de todo mal.

Recuerdo que era un novato.

Quería tener el mejor código.

Veo que desea lo mismo.

Sin embargo, preocuparse por cosas como esta no lo ayudará.

Solo tienes que escribir algunos juegos y ganar algo de experiencia.

Preocuparse por el rendimiento más tarde.

Answer 3

Espacio de nombres bastante seguro es solo una cosa de C++. EG cuando en el desensamblador xbox359 no tengo puntos de interrupción en cosas como el espacio de nombres. etc. Cosas como blah :: blahblah :: peoplewhosefoo se reduciría a 38 < 000000> que si recuerdo es saltar desde los puntos punteros actuales de la pila de puntos al + < 000000> bytes. Cuál podría ser esa función descrita arriba. Donde otros solo pueden estar (todavía no soy un experto en esta parte) pero creo locales de carga de cuadros y parámetros en r4 a r < ...>.

Pero puedes ignorar todo este texto y solo hacer el juego de 30 fps primero, luego encontrar los puntos de acceso/cuellos de botella del código y arreglarlo. En lugar de esta optimización% 0.01.

Que es efectivamente lo que se dijo anteriormente en otras respuestas.

Answer 4

La organización de los archivos fuente en el disco no afectará el rendimiento del ensamblado compilado. Tampoco utilizará la profundidad o amplitud de sus espacios de nombres dentro del código fuente.

Cuando mira el estándar ECMA para la CLI (# 335), específicamente la Partición II capítulo 22 de la misma, puede encontrar el formato de metadatos utilizado para describir tipos en un ensamblaje (la tabla lógica TypeDef). Puede ver que el nombre de tipo y el espacio de nombres de tipo son ambos índices en el heap de cadena: los índices en los metadatos CLI son pseudodinámicos, ya que están diseñados para tener siempre el tamaño mínimo necesario para indexar todos los elementos disponibles, por lo que el tamaño del índice del montón de cadenas en bytes reales puede variar, pero será el mismo para todos los tipos.

Cualquier acceso al espacio de nombre o nombre a través de los metadatos será, por lo tanto, un tiempo constante dentro del alcance de ese ensamblaje. El acceso a los datos que rodean el índice de espacio de nombres será igualmente constante (no será necesario realizar cálculos de longitud de cadena en tiempo lineal para "omitir" la cadena del espacio de nombres en los metadatos del tipo, ya que la cadena real está en el montón) .

Por lo tanto, realmente (*) no importa cuán profundamente anidados estén sus espacios de nombres, hasta que accedan a ellos en código mediante reflexión y comiencen a realizar operaciones de cadena de tiempo lineal sobre ellos. Pero en ese momento eso es cierto para cualquier operación de cuerda que realice.

(*) el número de espacios de nombres únicos y nombres u otros datos, obviamente, aumentará el tamaño del montón de cuerdas, pero ningún impacto que esto tiene sobre el rendimiento es muy bajo nivel y no siempre es necesariamente negativo.