¿El uso de tipos de datos pequeños (por ejemplo, corto en lugar de int) reduce el uso de memoria?

Question

Mi pregunta es básicamente sobre cómo el compilador de C# maneja la asignación de memoria de tipos de datos pequeños. Sé que, por ejemplo, los operadores como add se definen en int y no en short, por lo que los cálculos se ejecutarán como si los cortos fueran miembros int.

Suponiendo lo siguiente:

• No hay lógica en la lógica de negocio/validación asociada con la elección de corto como un tipo de datos
• No estamos haciendo nada con código no seguro

¿El uso el tipo de datos cortos, siempre que sea posible, reduce la huella de memoria de mi aplicación y ¿es aconsejable hacerlo? O está utilizando el uso de palabras cortas y similares que no valen la pena ya que el compilador asigna la cantidad total de memoria de un int32 por ejemplo y agrega conversiones adicionales al hacer aritmética.

Cualquier enlace sobre el supuesto impacto en el rendimiento del tiempo de ejecución sería muy apreciado.

preguntas relacionadas:

Why should I use int instead of a byte or short in C#

Integer summing blues, short += short problem

Answer 1

Desde una perspectiva solo de memoria, usar short en lugar de int será mejor. La simple razón es que una variable short solo necesita la mitad del tamaño de una variable int en la memoria. El CLR no expande short a int en la memoria.

Sin embargo, este consumo reducido de memoria puede y probablemente disminuirá significativamente el rendimiento del tiempo de ejecución de su aplicación. Todas las CPU modernas funcionan mucho mejor con números de 32 bits que con números de 16 bits. Además, en muchos casos, el CLR tendrá que convertir entre short y int cuando, por ejemplo, llamando a métodos que toman int argumentos. Hay muchas otras consideraciones de rendimiento que debe tomar antes de seguir por este camino.

Solo cambiaría esto en ubicaciones y módulos muy dedicados de su aplicación y solo si realmente encuentra una escasez de memoria mensurable.

En algunos casos, puede cambiar de int a short fácilmente sin dañar el rendimiento. Un ejemplo es una matriz gigante de int s, todas las cuales también se ajustan a short s.

Answer 2

Tiene sentido en términos de uso de memoria sólo si tiene en su programa de matrices muy grandes (o colecciones construidas en matrices como List<>) de estos tipos, o arreglos de estructuras empaquetadas compuestas por los mismos. Por 'grande' me refiero a que la huella de memoria total de estas matrices es un gran porcentaje del conjunto de trabajo y, un gran porcentaje de la memoria disponible. En cuanto a la conveniencia, me atrevo a aventurar que no es aconsejable usar tipos cortos a menos que los datos en los que opera su programa estén explícitamente especificados en términos de short etc., o el volumen de datos se ejecute en gigabytes.

Answer 3

Depende de lo que usa los calzoncillos. Además, ¿está asignando tantas variables que la huella de memoria va a importar?

Si este programa se va a utilizar en un dispositivo móvil o en un dispositivo con limitaciones de memoria, entonces podría preocuparme. Sin embargo, la mayoría de las máquinas actuales tienen al menos 1-2 gb de ram y tienen procesadores de doble núcleo bastante decentes. Además, la mayoría de los dispositivos móviles de hoy se están convirtiendo en mini computadoras bestiales. Si declaras tanto que ese tipo de máquina comenzaría a morir, entonces ya tienes un problema en tu código.

Sin embargo, en respuesta a la pregunta. Puede importar en máquinas con memoria limitada si declaras muchas variables de 4 bytes cuando solo necesitas una variable de 2 bytes para completarlas, entonces probablemente debas usar el short.

Si realiza cálculos complicados, raíces cuadradas y cálculos de alto valor. Entonces probablemente debería usar variables con más bytes para que no se arriesgue a perder ningún dato. Simplemente declare lo que necesita cuando lo necesite. Ponga el cero si lo ha hecho para asegurarse de que C# lo limpie, si le preocupan las limitaciones de la memoria.

Answer 4

En resumen, sí. Sin embargo, también debe tener cuidado con la alineación de la memoria.Puede encontrar Mastering C# structs y Memory alignment of classes in c#? útil

Answer 5

Cuando se trata del lenguaje de máquina, a nivel de registro, creo que es mejor alinearse con el tamaño de registro ya que la mayoría de las funciones de movimiento y aritmética se realizan en los límites del registro. Si la máquina tiene un registro de 32 bits, es mejor alinearse con 32 bits. Si la máquina tiene registros de 16 bits para operaciones de E/S, es una buena práctica alinearse con 16 bits para reducir el número de operaciones al mover el contenido.