Na końcówkę tego dnia przygotowałem artykuł, który będzie próbował obalić teorię, że mniejszy zakres danych to zawsze lepszy wybór. Dysponujecie szerokim wachlarzem różnych zakresów typów danych (zależy też jaki język). C i C++ na ten przykład mają "int" jak każdy inny język, ale dysponują również typem "short", "long" czy nawet "long long". Byłbym zapomniał, są też podziały na typ ze znakiem ("signed") i bez znaku ("unsigned"). W niektórych sytuacjach człowiek jest absolutnie pewny, że niektóre wartości NIGDY nie będą musiały potrzebować ujemnych liczb, na przykład liczba użytkowników w bazie danych. Jeden programista to wie, drugi to wie, koledzy tego drugiego też to wiedzą, a mimo wszystko ludzie na upartego trzymają się kurczowo standardowego rodzaju "int". Co to może oznaczać? Czemu mimo tych "pewniaków", że pewne zakresy czy zbyt duże liczby nie będą wcale potrzebne, twórcy kodu wciąż wykorzystują typ danych "int"? Przeczytajcie moje hipotezy, a być może chociaż częściowo postaram się ukoić Waszą ciekawość.
| Tweet |
TYP DANYCH "INT" Z PUNKTU WIDZENIA KOMPUTERA
Jest faktem niezaprzeczalnym, że użycie typu "short" będzie z pewnością "tańsze" od zwykłej liczby całkowitej. Zgodnie ze standardem C, typ "short" jest mniejszy albo co najwyżej równy typowi "int" w zależności od architektury systemu. Tu macie absolutną rację. Natomiast patrzenie na jak najbardziej oszczędne gospodarowanie pamięcią podczas procesu programu jest po prostu niewłaściwe! OK, 30 lat temu to miało duże znaczenie, bo ówczesne komputery nie były zaopatrzone w takie gigantyczne zakresy pamięci RAM jakie mamy dzisiaj, natomiast dla dzisiejszego procesora to, czy pobierzemy 4 bajty danych (typ danych "int"), czy tylko 2 (typ danych "short"), nie robi żadnej drastycznej różnicy w działaniu! Takie widzenie powoduje, że działamy wprost przeciwnie, możemy sobie zaszkodzić i też spowodować, że będzie źle! W czym tkwi sedno?
DZIAŁANIE PROCESORA "POD MASKĄ"
Wiemy już, że "short" jest (przeważnie) o połowę mniejszy od typu "int", natomiast to nie jest koniec istotnych wniosków. Może Wam przez to spaść wydajność! Z jednego prostego powodu: procesor dużo lepiej poradzi sobie ze zwykłym typem "integer" niż każdym innym, bo to jest najbardziej naturalny typ danych. Tym bardziej, że języki też stosują automatyczną konwersję typów, aby jak najlepiej dopasować się do sytuacji. Nawet jeśli przypiszecie zmiennej typu "short" iloraz 20 / 4 to co Wy myślicie, że od samego początku zarówno dzielna, jak i dzielnik są od razu typami "short"? NIE! Procesor działa zupełnie inaczej niż sądzicie...
CHCESZ LEPIEJ, A MOŻESZ ZASZKODZIĆ!
Liczba 20 oraz liczba 4 to jest typ danych "int". Dzielenie w postaci 20 / 4 też jest traktowane jak "int", a wynik też pozostaje tego samego typu. W chwili przypisywania tej wartości do zmiennej typu "short" to właśnie w tym miejscu nakładacie procesorowi dodatkową robotę, bo aby prawidłowo przypisać tę wartość zmiennej o krótszym zakresie liczb całkowitych, musi najpierw odpowiednio "skrócić" ten zakres aby go dopasować do typu. Gdybyśmy zostawili zwykły "int", to zadanie procesora skończyłoby się na obliczeniu ilorazu i przypisania go zmiennej. Teraz rozumiecie czemu to może zaszkodzić? Wyobraźcie sobie teraz, że jest do wykonania tysiące takich obliczeń tylko jeszcze bardziej skomplikowanych, a po każdym policzeniu trzeba to jeszcze skracać do odpowiedniego zakresu. Dwa razy więcej roboty dla CPU.
HISTORYJKA PEŁNA ABSURDU
Aby to lepiej Wam zobrazować wyobraźcie sobie, że macie za zadanie napisanie tysiąca listów do swoich znajomych. To będzie sytuacja identyczna do obliczania wyrażeń. Następnie taki list wrzucacie do koperty, liżecie znaczek i kopertę z listem odkładacie na miejsce obok. To jest moment przypisywania wartości. W tej chwili pojawia się ktoś złośliwy i każe Wam jeszcze przyciąć teraz starannie te koperty z listami bo skrzynka okazała się zbyt mała, żeby wrzucić je bez obróbki. To jest właśnie moment w którym typ danych "int" (czyli ten nasz list) staje się za duży i trzeba go skrócić, aby "pasował" do typu "short". A gdyby skrzynka na listy była większa, to uniknęlibyśmy tego. Mam nadzieję że ta historyjka, choć trochę pozbawiona sensu, pozwoli Wam głębiej pomyśleć dlaczego korzystanie z mniejszych zakresów danych po prostu się NIE OPŁACA. Na dodatek pomyślcie o tych wszystkich funkcjach, które przyjmują "int" lub zwracają "int". Też dojdzie do automatycznej konwersji do "short" po policzeniu lub wprowadzeniu wartości.
Jedynym wyjątkiem, który brzmi jak sensowne usprawiedliwienie to tablica (albo inna struktura danych) o gigantycznych rozmiarach. Gdy mamy do czynienia z 10,000 elementów, to wtedy faktycznie możemy pokusić się o tę oszczędność i pozwolić sobie na ustalenie konkretnego typu czy to ma być "short", "long", czy "unsigned", czy nie. Przy pojedynczych wartościach, nie ma sensu sobie zawracać głowy. Naprawdę.
To koniec mojej wypowiedzi na ten temat. Powtarzam: to są tylko moje przypuszczenia! Może tak być, a może tak nie być.