Mam pytanie odnośnie typów danych stosowanych w aplikacjach. Jeśli wiemy, że nie potrzebujemy przechowywać liczb większych niż np 100 to czy powinno się wtedy stosować typ byte zamiast int? Czy to dobry nawyk czy zbędny bajer, bo w końcu w obecnych czasach RAMu mamy sporo:) W szkole nikt nie zwraca na to uwagi, lecz jak to wygląda w zastosowaniach profesjonalnych? Każdy bajt pamięci się wtedy liczy? Piszę właśnie program, który będzie stosować w iteracjach liczby nie większe od 20 i mam dylemat. Niby durna sprawa, ale wolę aby wypowiedzieli się doświadczeni.
0
0
Ja tam stosuje to;p
Może przy małych programach to nie daję dużo ale przy naprawdę rozbudowanych gdzie są niezliczone ilości liczb różnica pewnie jest spora;d
0
Absolutnie nie ma to znaczenia i najlepiej korzystać z "domyślnego" inta (coby potem nie musieć gdzieś rzutować). Oczywiście nie jest też tak, że typy mniejsze niż int się nie przydają (I/O, jakieś niskopoziomowe operacje).
1
Primo: JVM alokuje obiekty na granicy 8 bajtów chyba, jeśli twój obiekt będzie miał np 3 bajty to zajmie w pamięci i tak 8, podobnie jeśli będzie miał 9 bajtów to zajmie i tak 16 bajtów. Secundo: każdy obiekt ma chyba 4 czy 8 bajtów narzutu na vptr + inne bajery (jak np flaga z lockiem czy może jakieś flagi dla odśmiecacza). Wobec tego często polowanie na pojedyncze bajty nic nie daje.
Na pewno zmiana z int[dużo] na byte[tyle samo] (czyli chodzi mi o tablice) powinna dać wyraźną poprawę zarówno wydajności jak i zajętości pamięci.
0
Ja swojego czasu korzystalem z byte, short itp, obecnie na co dzien uzywam inta, chyba ze pisze cos co naprawde wymaga bytow, jak wlasna serializacja itp, po to, aby jak najmniej przesylac itp. Wibowit ma duzo racji z tym wyrownywaniem JVM. Jednym slowem, uwazam ze dla standardowym 'aplikacji biznesowych' ram jest duzo tanszy niz moj czas spedzony na szukaniu bledow gdzie np. miala byc wartosc 255 a sie okazalo ze jest -128 i przy awansie do inta zostaje -128 bo ktos gdzies zapomnial zrobic &0xFF czy cos podobnego (Java nie ma typow unsigned).
0
z jednej strony zmniejszenie rozmiaru może poprawić humor pamięci cache, lecz z drugiej gdy czytamy byte a liczymy na int dodajemy instrukcję rozszerzenia bajtu do słowa, pamiętam że czasem kosztowało to całkiem sporo.
Jak rodzi sobie współczesny procesor i kompilator nie wiem.
Rozsądzić może tylko debuger i profiler.
1
ZTCP na 386+ rozszerzanie jest praktycznie za darmo.
"Humor pamięci cache" zależy od asocjacyjności. Agner Fog opisał działanie/ adresowanie pamięci cache dość dobrze w swoich poradnikach, nie chce mi się tego kolejny raz powtarzać, więc odsyłam: www.agner.org/optimize