Powinienem używać bajtu czy int?

Zwykle tak, 32-bitowe liczby całkowite będą działać nieco lepiej, ponieważ są już prawidłowo wyrównane dla własnych instrukcji procesora. Powinieneś używać mniejszego typu numerycznego tylko wtedy, gdy naprawdę potrzebujesz przechowywać coś o tym rozmiarze.

Powinieneś użyć wyliczenia DayOfWeek, chyba że istnieje ważny powód, aby tego nie robić.

DayOfWeek day = DayOfWeek.Friday;

Aby wyjaśnić, ponieważ zostałem zdegradowany w głosowaniu:
Dobrze
Twój kod jest prawie zawsze ważniejszy niż

wydajność
, zwłaszcza gdy mówimy o tak małej różnicy. Jeśli użycie wyliczenia lub klasy, która reprezentuje semantykę danych (czy to wyliczenie DayOfWeek, czy inne wyliczenie, klasa Gallons lub Feet) sprawia, że ​​kod jest bardziej przejrzysty lub łatwiejszy w utrzymaniu, pomoże Ci to osiągnąć punkt, w którym możesz bezpiecznie optymalizować.

int z;

int x = 3;

int y = 4;

z = x + y;

Może się kompilować. Ale nie ma sposobu, aby dowiedzieć się, czy robi coś inteligentnego, czy nie.

Gallons z;

Gallons x = new Gallons(3);

Feet y = new Feet(4);

z = x + y;

To się nie skompiluje, a nawet patrząc na to, oczywiste jest, dlaczego nie - dodaj galony do stóp

nie ma sensu

.

Moje domyślne położenie jest próbowanie użycia silnych typów, aby dodać ograniczenia do wartości - gdzie znasz je z wyprzedzeniem. Tak więc, w swoim przykładzie może być korzystne użycie

Byte DayofWeek

, ponieważ jest bliżej żądanego zakresu wartości.
Oto moje rozumowanie; na przykładzie przechowywania i przekazywania części rocznej daty. Część roku - patrząc na inne części systemu związane z SQL Server DateTimes są ograniczone do 1753 do 9999 (zauważ, że możliwy zakres C # dla DateTime jest inny!) Więc

short

obejmuje moje możliwe wartości, a jeśli spróbuję przekazać coś więcej, kompilator ostrzeże mnie przed kompilacją kodu. Niestety w tym konkretnym przykładzie właściwość C # DateTime.Year zwróci wartość int - w ten sposób zmuszając mnie do rzutowania wyniku, jeśli muszę przekazać, na przykład,

DateTime.Now.Year

do mojej funkcji .
Ta pozycja wyjściowa wynika z długoterminowych rozważań dotyczących przechowywania danych milionów wierszy i miejsca na dysku - nawet jeśli jest tani (znacznie tańszy, gdy hostujesz i uruchamiasz SAN lub coś w tym rodzaju).
W innym przykładzie bazy danych użyję mniejszych typów, takich jak bajt (SQL Server tinyint) do wyszukiwania identyfikatorów, gdzie jestem pewien, że nie będzie wielu typów wyszukiwania, aż do długich (SQL Server bigint) dla id, gdzie prawdopodobnie będzie więcej wpisów.
Moje praktyczne zasady to:

• Jeśli to możliwe, najpierw sprawdź poprawność. Oczywiście użyj DayOfWeek w swoim przykładzie :)
• Wybierz typ odpowiedniego rozmiaru w ten sposób, korzystając z kontroli bezpieczeństwa kompilatora, która jak najszybciej pokaże Ci błędy;
• ... ale kompensowane przez ekstremalne wymagania dotyczące wydajności i prostoty, szczególnie tam, gdzie nie ma miejsca na przechowywanie długoterminowe lub gdy mamy do czynienia z tabelą przeglądową (mała liczba wierszy), a nie transakcyjną (duża liczba wierszy).

Ze względu na przejrzystość, pamięć DB kurczy się wolniej, niż można by się spodziewać, zmniejszając typy kolumn z bigintów do mniejszych. Jest to spowodowane zarówno wcięciami do granic słów, jak i wewnętrznymi problemami z rozmiarem strony DB. Jednak prawdopodobnie przechowujesz każdy fragment danych wiele razy w swojej bazie danych, prawdopodobnie zachowując historyczne rekordy, gdy się zmieniają, a także zachowując kopie zapasowe z ostatnich kilku dni i kopie zapasowe dziennika. Zatem zaoszczędzenie kilku procent potrzeb w zakresie pamięci masowej przyniesie długoterminowe oszczędności w kosztach przechowywania.
Nigdy osobiście nie napotkałem problemów, w których bajty w wydajności pamięci w porównaniu z ints były problemem, ale spędziłem wiele godzin, aby ponownie przydzielić miejsce na dysku i całkowicie wyłączyć serwery na żywo, ponieważ nie było ani jednej osoby dostępnej do monitorowania i zarządzania takimi rzeczami.

<strike>
System.DayOfWeek
</strike>
MSDN
http://msdn.microsoft.com/en-u ... .aspx
Używaj int przez większość czasu. Nie dla wydajności, ale dla prostoty.

Użyj int. Pamięć komputera jest adresowana za pomocą „słów”, które mają zwykle długość 4 bajtów. Oznacza to, że jeśli chcesz pobrać jeden bajt danych z pamięci, procesor musi pobrać całe 4-bajtowe słowo z pamięci RAM, a następnie podjąć dodatkowe kroki, aby wyodrębnić jeden bajt, który Cię interesuje. Kiedy myślisz o wydajności, procesorowi będzie znacznie łatwiej wyodrębnić całe słowo i skończyć z nim.
W rzeczywistości w rzeczywistości nie zauważysz żadnej różnicy między nimi pod względem wydajności (z wyjątkiem rzadkich, ekstremalnych okoliczności). Dlatego wolę używać int zamiast bajtu, ponieważ możesz przechowywać duże liczby z niewielkimi lub żadnymi karami.

Jeśli chodzi o przestrzeń dyskową, użyj

byte

, a jeśli chodzi o wydajność, cpu użyj

int

.