Должен ли я использовать байт или int?

Ответ 1

Обычно да, 32-битное целое число будет работать немного лучше, потому что оно уже правильно выровнено для собственных инструкций CPU. Вы должны использовать только числовой тип меньшего размера, когда вам действительно нужно хранить что-то такого размера.

Ответ 2

Вы должны использовать перечисление DayOfWeek, если нет веских причин не делать этого.

DayOfWeek day = DayOfWeek.Friday;

Чтобы объяснить, поскольку я был ниспроверен:

Правильность вашего кода почти всегда более важна, чем производительность, особенно в тех случаях, когда мы говорим об этой небольшой разнице. Если использование перечисления или класса, представляющего семантику данных (независимо от того, является ли оно перечислением DayOfWeek или другим перечислением или классом галлонов или футов) делает ваш код более четким или более удобным для обслуживания, это поможет вам добраться до точки, где вы можете безопасно оптимизировать.

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

Это может скомпилироваться. Но нет никакого способа узнать, не делает ли это что-либо здравомыслящее или нет.

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

Это не скомпилируется, и даже глядя на него, очевидно, что нет - добавление галлонов к ногам не имеет смысла.

Ответ 3

Моя позиция по умолчанию - попытаться использовать сильные типы, чтобы добавить ограничения к значениям - там, где вы знаете это заранее. Таким образом, в вашем примере может быть предпочтительнее использовать byte dayOfWeek, потому что он ближе к вашему желаемому диапазону значений.

Вот мои рассуждения; на примере хранения и передачи годовой части даты. Годовая часть - при рассмотрении других частей системы, которые включают SQL Server DateTimes, ограничена 1753 до 9999 (примечание С# возможный диапазон для DateTime отличается!) Таким образом, short охватывает мои возможные значения, и если я попытаюсь пройти что-либо большее, компилятор предупредит меня, прежде чем код будет компилироваться. К сожалению, в этом конкретном примере свойство С# DateTime.Year вернет int, что заставило меня отличать результат, если мне нужно пройти, например. DateTime.Now.Year в мою функцию.

Эта начальная позиция определяется соображениями долгосрочного хранения данных, предполагая "миллионы строк" ​​и дискового пространства, даже если она дешевая (она намного дешевле, когда вы размещаете и запускаете SAN или аналогичную).

В другом примере DB я буду использовать более мелкие типы, такие как байты (SQL Server tinyint) для идентификатора поиска, где я уверен, что не будет много типов поиска, до долгого (SQL Server bigint) для id, где есть вероятно, будет больше записей. т.е. для покрытия транзакционных записей.

Итак, мои эмпирические правила:

• Сначала пойдите, если это возможно, для правильности. Используйте DayOfWeek в вашем примере, конечно:)
• Перейдите к типу соответствующего размера, таким образом, используя проверки безопасности компилятора, дающие вам ошибки как можно скорее;
• ... но компенсируется чрезмерными потребностями в производительности и простотой, особенно там, где не задействовано долгосрочное хранилище, или где мы рассматриваем таблицу поиска (таблица с низким числом строк), а не транзакционную (большое количество строк).

В интересах ясности хранилище БД имеет тенденцию не сокращаться так быстро, как вы ожидаете, сокращая типы столбцов от bigint до более мелких. Это происходит из-за заполнения границ слов и проблем с размером страницы, внутренних для БД. Тем не менее, вы, вероятно, сохраняете каждый элемент данных несколько раз в своей БД, возможно, путем хранения исторических записей по мере их изменения, а также для хранения последних нескольких дней резервных копий и резервного копирования журналов. Таким образом, экономия нескольких процентов ваших потребностей в хранении будет иметь долгосрочную экономию на стоимости хранения.

Я никогда не испытывал лично проблем, когда проблема с памятью в байтах против ints в памяти была проблемой, но я потратил часы и часы, чтобы перераспределить дисковое пространство и полностью заблокировать серверы в реальном времени, потому что не было ни одного человека, доступного контролировать и управлять такими вещами.

Ответ 4

  System.DayOfWeek

MSDN

Забастовкa > Большую часть времени используйте int. Не для производительности, а простоты.

Ответ 5

Использовать int. Память компьютера адресуется словами "слова", которые обычно составляют 4 байта. Это означает, что если вы хотите получить один байт данных из памяти, CPU должен извлечь всего 4-байтового слова из ОЗУ, а затем выполнить некоторые дополнительные шаги, чтобы изолировать один байт, который вас интересует. Когда вы думаете о производительности, CPU будет намного проще извлекать целое слово и делать с ним.

Фактически во всей реальности вы не заметите какой-либо разницы между ними в отношении производительности (за исключением редких экстремальных обстоятельств). Вот почему мне нравится использовать int вместо байта, потому что вы можете хранить большие числа с практически не штрафом.

Ответ 6

В терминах объема хранения используйте byte и с точки зрения производительности процессора используйте int.