¿Debo usar byte o int?

Question

Recuerdo haber leído en alguna parte que es mejor (en términos de rendimiento) usar Int32, incluso si solo requiere Byte. Se aplica (supuestamente) solo a casos en los que no le importa el almacenamiento. Es esto valido?

Por ejemplo, necesito una variable que contenga un día de la semana. ¿Es

int dayOfWeek; 

o

byte dayOfWeek; 

EDITAR: chicos, soy consciente de DayOfWeek enumeración. La pregunta es sobre otra cosa.

Answer 1

Normalmente, un entero de 32 bits tendrá un mejor rendimiento porque ya está alineado correctamente para las instrucciones nativas de la CPU. Solo debe usar un tipo numérico de menor tamaño cuando realmente necesite almacenar algo de ese tamaño.

Answer 2

System.DayOfWeek

MSDN

La mayor parte del tiempo de uso int. No por rendimiento, sino por simplicidad.

Answer 3

Debe utilizar la enumeración DayOfWeek, a menos que haya una razón importante para no hacerlo.

DayOfWeek day = DayOfWeek.Friday; 

de explicar, ya que estaba downvoted:

El corrección de su código es casi siempre más importante que el rendimiento , especialmente en los casos en los que estamos hablando de esta pequeña diferencia . Si usa una enumeración o una clase que represente la semántica de los datos (ya sea la enumeración de DayOfWeek, u otra enumeración, o una clase de Galones o Pies) hace que su código sea más claro o más fácil de mantener, lo ayudará a llegar al punto donde pueda. optimizar de forma segura.

int z; 
int x = 3; 
int y = 4; 
z = x + y; 

Eso puede compilar. Pero no hay forma de saber si está haciendo algo sensato o no.

Gallons z; 
Gallons x = new Gallons(3); 
Feet y = new Feet(4); 
z = x + y; 

Esto no se compilará, e incluso mirarlo es obvio por qué no - añadiendo galones a Pies no tiene sentido.

Answer 4

Use una int. La memoria de la computadora se trata con "palabras", que suelen tener una longitud de 4 bytes. Lo que esto significa es que si desea obtener un byte de datos de la memoria, la CPU tiene que recuperar la palabra completa de 4 bytes de la RAM y luego realizar algunos pasos adicionales para aislar el byte único que le interesa. Cuando piensa sobre el rendimiento, será mucho más fácil para la CPU recuperar una palabra completa y terminar con ella.

De hecho, en realidad, no notará ninguna diferencia entre los dos en cuanto a rendimiento se refiere (excepto en circunstancias extremas raras). Es por eso que me gusta utilizar int en lugar de byte, porque puedes almacenar números más grandes sin penalización.

Answer 5

Mi posición predeterminada es tratar de usar tipos fuertes para agregar restricciones a los valores, donde los conoce con anticipación.Por lo tanto, en su ejemplo, puede ser preferible utilizar byte dayOfWeek porque está más cerca de su rango de valores deseado.

Aquí está mi razonamiento; con el ejemplo de almacenar y pasar un año-parte de una fecha. La parte del año: al considerar otras partes del sistema que incluyen SQL Server DateTimes, está limitada a 1753 a 9999 (observe que el rango posible de C# para DateTime es diferente). Por lo tanto, un short cubre mis valores posibles y si intento pasar algo más grande el compilador me avisará antes de que el código compile. Desafortunadamente, en este ejemplo en particular, la propiedad C# DateTime.Year devolverá un int, lo que me obligará a emitir el resultado si necesito pasar, p. DateTime.Now.Year en mi función.

Esta posición inicial se basa en consideraciones de almacenamiento a largo plazo de datos, asumiendo 'millones de filas' y espacio en disco, aunque es barato (es mucho menos económico cuando está alojado y ejecuta una SAN o similar).

En otro ejemplo de DB, utilizaré tipos más pequeños como byte (SQL Server tinyint) para ID de búsqueda donde estoy seguro de que no habrá muchos tipos de búsqueda, hasta long (SQLint bigint) para id donde hay es probable que sean más registros. es decir, para cubrir registros transaccionales.

Así que mis reglas de oro:

1. Ir por la corrección primero, si es posible. Use DayOfWeek en su ejemplo, por supuesto :)
2. Vaya por un tipo de tamaño apropiado, haciendo uso de las comprobaciones de seguridad del compilador que le dan errores lo antes posible;
3. ... pero contrarrestan las necesidades extremas de rendimiento y simplicidad, especialmente cuando no se trata de almacenamiento a largo plazo, o cuando consideramos una tabla de búsqueda (conteo bajo de filas) en lugar de una cuenta transaccional (conteo alto de filas).

En aras de la claridad, el almacenamiento de la base de datos no se contrae tan rápido como se espera al reducir los tipos de columnas de bigint a tipos más pequeños. Esto se debe tanto al relleno de los límites de las palabras como a los problemas de tamaño de página internos de la base de datos. Sin embargo, probablemente almacene cada elemento de datos varias veces en su base de datos, quizás almacenando registros históricos a medida que cambian, y también manteniendo los últimos días de copias de seguridad y copias de seguridad de registros. Así que ahorrar un pequeño porcentaje de sus necesidades de almacenamiento tendrá un ahorro a largo plazo en el costo de almacenamiento.

Nunca he tenido problemas personales cuando el rendimiento en memoria de los bytes frente a los ints ha sido un problema, pero he perdido horas y horas teniendo que reasignar el espacio en disco y tener los servidores en vivo completamente puestos porque no había una sola persona disponible para monitorear y administrar tales cosas.

Answer 6

En términos de cantidad de almacenamiento, use byte y en términos de rendimiento de la CPU, use int.