Powinienem używać bajtu czy int?
Pamiętam, że czytałem gdzieś, że lepiej (z punktu widzenia wydajności) używać Int32, nawet jeśli potrzebujesz tylko bajtu. Dotyczy to (prawdopodobnie) tylko wtedy, gdy nie zależy Ci na przechowywaniu. Czy naprawdę tak jest?
Na przykład potrzebuję zmiennej, która będzie zawierać dzień tygodnia. I wiem
int dayOfWeek;
lub
byte dayOfWeek;
EDIT
:
Chłopaki, wiem o wyliczeniu DayOfWeek. Pytanie jest inne.
Nie znaleziono powiązanych wyników
Zaproszony:
Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się
6 odpowiedzi
Anonimowy użytkownik
Potwierdzenie od:
Anonimowy użytkownik
Potwierdzenie od:
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ć.
Może się kompilować. Ale nie ma sposobu, aby dowiedzieć się, czy robi coś inteligentnego, czy nie.
To się nie skompiluje, a nawet patrząc na to, oczywiste jest, dlaczego nie - dodaj galony do stóp
nie ma sensu
.
Anonimowy użytkownik
Potwierdzenie od:
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 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, 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:
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.
Anonimowy użytkownik
Potwierdzenie od:
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.
Anonimowy użytkownik
Potwierdzenie od:
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.
Anonimowy użytkownik
Potwierdzenie od: