Also folgende Frage:
Macht es sinn, wenn man weiß dass ein wert zum beispiel nie größer als 127 / -128
sein wird / sollte, zum Beispiel statt int einfach byte zu verwenden?
Oder eben, wenn man die Werte menge genau einschätzen kann, zB short statt int?
Also, mir ist klar, das man vom speicher nicht mehr als ein paar bytes spaart, und dass
wird man auch bei 1ner million variablen nicht merken, denke ich - aber so rein semantisch?
Oder ist davon abzuraten?
Vielen Dank.
[QUOTE=mymaksimus]Macht es sinn, wenn man weiß dass ein wert zum beispiel nie größer als 128 / -128
sein wird / sollte,[/QUOTE]
Der Wertebereich von byte ist -128 bis 127.
[QUOTE=mymaksimus;73390][…]zum Beispiel statt int einfach byte zu verwenden?
Oder eben, wenn man die Werte menge genau einschätzen kann, zB short statt int?[/QUOTE]
Ja, das würde ich so machen. Dabei geht es nicht primär daraum, Speicher zu sparen, sondern einfach den richtigen Datentyp zu wählen.
Ist zu empfehlen.
oke, danke ^^
hat sich ja dann gelöst, aber vielleicht wollen ja noch andere ihren senf dazu geben, also lass ichs mal offen.
stimmt war ja -127, ist geändert ,danke
[quote=mymaksimus]stimmt war ja -127[/quote]eben nich! -128(1000 0000b)/+127(0111 1111b)
bye
TT
http://stackoverflow.com/questions/2380696/java-short-integer-long-performance
Generell würde ich davon abraten. Kleines Beispiel. Du hast ein Program das irgendwelche Logs auswertet. Du weißt das es immer 10 Logs sind. Also nimmst du short oder sogar Byte. Jetzt ändert sich aber die Anzahl der logs plötzlich auf 10.000. Dein Programm fliegt gehörig aufs Maul. Ich nehme eigentlich immer int wenn es um ganzzahlige Zahlen geht. Wenn ich weiß das int nicht reicht natürlich long. Short oder Byte ist natürlich interessant wenn du sehr sehr große Datenmenge mit wenig Zahlen verwalten musst oder auf kleinen Geräten mit wenig Ram arbeitest. Sonst würde ich eigentlich immer int nehmen.
[QUOTE=Timothy_Truckle;73398]eben nich! -128(1000 0000b)/+127(0111 1111b)
bye
TT[/QUOTE]
ups - fail xD meinte natürlich das 
[QUOTE=Prototype]http://stackoverflow.com/questions/2380696/java-short-integer-long-performance
Generell würde ich davon abraten. Kleines Beispiel. Du hast ein Program das irgendwelche Logs auswertet. Du weißt das es immer 10 Logs sind. Also nimmst du short oder sogar Byte. Jetzt ändert sich aber die Anzahl der logs plötzlich auf 10.000. Dein Programm fliegt gehörig aufs Maul. Ich nehme eigentlich immer int wenn es um ganzzahlige Zahlen geht. Wenn ich weiß das int nicht reicht natürlich long. Short oder Byte ist natürlich interessant wenn du sehr sehr große Datenmenge mit wenig Zahlen verwalten musst oder auf kleinen Geräten mit wenig Ram arbeitest. Sonst würde ich eigentlich immer int nehmen.[/QUOTE]
Also das Beispiel mit den Logs hinkt. Nimm doch lieber ein Fingerzählprogramm, oder Wochentage, wie soll mir da die Anzahl ungeplant explodieren? 
Außerdem kann man dein „eigentlich immer int nehmen“ ja genau so sehen, das kann dir auch unerwartet um die Ohren fliegen. Man muss halt nur abschätzen, ob der Datentyp „geplant und eigentlich“ ausreicht, oder ob er garantiert ausreicht.
[quote=mymaksimus]Macht es sinn, wenn man weiß dass ein wert zum beispiel nie größer als 127 / -128
sein wird / sollte, zum Beispiel statt int einfach byte zu verwenden?[/quote]
Das ist Compiler und Prozessorabhängig. Wenn Du einen handelsüblichen Desktop-PC nimmst, macht es nur ein paar Bytes Unterschied im Programm. Mehr nicht. Bei der Datenübertragung ist schon byte nötig und char für Unicode (&Co). Die restlichen Datentypen (außer float) dürften aus historischen Gründen noch vorhanden sein, als man wirklich auf Speicher achten musste. Ich habe diese jedenfalls noch nie gebraucht. int, float, byte (bzw. char) decken bei mir den größten Bedarf.
Wenn Du mal in die Microcontroler Ecke schaust, wird es wirklich interessant. Hier hast Du durchaus wirklich Vorteile umd Platz zu sparen. Allerdings gibt es auch µC wo alle Datentypen 32 Bit breit sind, egal ob char, short oder boolean.
*** Edit ***
Mutation - Wochen-Schalt-Tag - …
Jup, einzig alleine beim Mikrocontroller oder Netzwerk interessant.
Häwas? Nein. Nicht so. Selbst wenn man eine Variable hat, die nie größer als ein byte wird, kann man einen int verwenden. Es macht keinen Unterschied. In der .class-Datei gibt’s nur 32bittige Werte (also ints), und beim Rechnen auf dem Stack liegen auch immer ints (longs und doubles werden “umständlich aus 2 Hälften zusammengebaut”). Aber ansonsten gibt es keinen Grund, irgendwo sowas wie byte oder short zu verwenden.
Aaaaauuußer…
…bei Arrays. Ob man einen byte[1000] oder einen int[1000] hat, macht schon einen Unterschied. Aber bei einzelnen Variablen nicht.
„Medizinischer Bericht vom dritten Freitag der 41. KW. Dem Patient ist der 48. Finger gewachsen“ → Den Typ hätte ich gerne als Keyboarder 
Nee, schon klar worauf du hinaus willst.
Könnte nicht auch ein Grund sein, ein sauberes Interface zur Datenbank zu erhalten? Bei vielen Datensätzen ist ein kleinerer Datentyp in der DB doch aus Platzgründen immer noch sinnvoll, oder? Und wenn mein Datenfeld in der DB durch einen Short repräsentiert wird, wäre es doch fahrlässig im Code einen Integer zu verwenden?
öhm - nö. In der Datenbank werden 16 Bit verwendet, das Programm verwendet 32 Bit. Wenn es dann knallt, liegt ein Fehler im Programm vor oder die DB ist falsch designt. Dann stimmt eh irgend was nicht.
Okay, wieder was gelernt. Danke!
ah - interessant und vermerkt
wie ist das dann be 64 Bit VM. Da macht das ja keinen Sinn aus 2 32 Bit ein 64 Bit zusammen zu kleben?
Ich meine mal gelesen zu haben, dass an manchen Stellen in der JVM mit Integer performanter umgegangen werden kann als mit Short oder Byte … Quelle hab ich leider grad keine zur Hand. Müsste ich nochmal suchen.
Die Frage “int, oder doch lieber byte?” stelle ich mir eigentlich nur, wenn es um das Thema Traffik geht. Wenn ich in einer Klasse, weshalb auch immer, eine (Ganz-)Zahl speichern muss, nehm ich eigentlich immer int. Ausnahme: Filegrößen und DInge wo ich weiß, dass long eindeutig abgebrachter wäre.
[update]
War nicht die Quelle die ich im Kopf hatte, aber die erste Antwort hier trifft es recht gut: http://stackoverflow.com/questions/14531235/in-java-is-it-more-efficient-to-use-byte-or-short-instead-of-int-and-float-inst
Nichtsdestotrotz wähle ich normalerweise den passenden Datentyp. Denn die Wahl des Datentyps hat auch eine Aussage: der gespeicherte Wert befindet sich im Wertebereich x-y.
Ich hatte oben ja geschrieben, dass ich das nicht aus Performance- oder Speichergründen mache, sondern einfach nur, um den passenden Datentyp zu wählen.
Wenn der Wertebereich irgendwann mal doch nicht mehr passen sollte, dann refactore ich halt. Wobei das eher nicht vorkommt, weil passend für mich bedeutet, dass die Menge auf natürliche Weise beschränkt ist.
Also für Zahlen byte zu verwenden, auch wenn sie sehr klein sind halte ich für falsch, da ist doch auch die Repräsentation des Datentyps nicht gegeben. Für Ganzzahlen sollte man short, int, long nehmen. Dass Java jetzt mit ints besser als mit shorts umgeht ist imo eher ein Detail für die Performanceoptimierer und ich schätze mal das kann auch von der verwendeten JVM abhängen.
@mogel : Wenn in der Datenbank ein Short steht ist es mMn nicht zu empfehlen im Java Programm daraus ein Integer zu machen. Das lädt ja gerade zu zum Überschreiten der Datentypsgrenzen ein.
[QUOTE=mogel]
wie ist das dann be 64 Bit VM. Da macht das ja keinen Sinn aus 2 32 Bit ein 64 Bit zusammen zu kleben?[/QUOTE]
Ohne die Implementierungsdetails aller VMs zu kennen: Die JVM geht einfach von 32bit aus. Es gibt Instruktionen, um ein Element zu laden (für ints und floats), und welche, um zwei Elemente zu laden (für long und double). Natürlich würde eine 64bit-VM z.B. ein ‘ladd’ dann in ihren 64bit-Registern machen, aber der Bytecode und seine Semantik müßten ja gleich bleiben. (Details rund um http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.html#jvms-2.11.1 herum…)
Marco schrieb ja auch “In einer .class-Datei”, und nicht “Im Stack der spezifischen VM”. Und da nun mal Bytecode-Kompatibilität eine von Javas Eigenschaften ist gilt folglich die Regel das ein Byte aus einem 64Bit Compiler auf einer 32Bit VM laufen muss. Also wird im Bytecode auch “der umständliche Weg” über das Laden von 2 32Bit-Werten stehen. Was der Performance-Optimizer einer spezifischen 64Bit-VM dann daraus für die physische CPU macht ist implementierungsabhängig.