Object Initialisierung

[specialize]

Hallo,

zur Zeit handhabe ich es so, dass wenn ich ein Objekt in mehr als einer Methode benutze, es am Anfang initialisiere(oftmals ohne spezifischen Wert) und dann in der Methode dem Objekt einen Wert zuordne).
Wenn ich es nur in einer Methode benutze, initialisiere ich es in der Methode.

1) Was ist die bessere Lösung in hinsicht auf Schnelligkeit, Speicherbedarf,.. und warum?

2) Wenn ich es in der Methode initialisiere, kommt der Garbage collector am Ende der Methode?

 

[faetzminator]

Speichert diese Variable irgendwelche Werte zwischen den Methodenaufrufen? Oder ist sie einfach nur deklariert, damit sie nicht in jeder Methode deklariert werden muss?
Aber ganz grundsätzlich: Immer nur so lokal wie möglich halten. Ich halte auch so was nicht für sinnvoll:

String foo;
// some code
foo = ...;

Sondern

// some code
String foo = ...;

Edit:
1) Vergiss das ganz schnell wieder. Kümmer dich nicht drum.
2) Jain, er kommt irgendwann irgendwo, aber auch da zählt 1)

 

[M_Schaffrath]

Also die Code Conventions sehen vor, Variablen so lokal wie möglich zu halten, immer am Anfang eines Blocks zu deklarieren und möglichst bei der Deklaration zu initialisieren.

Ich denke nicht, dass die letzteren beiden Punkte irgendeinen Einfluss auf die Performance haben.

 

[vonAltmann]

1) Was ist die bessere Lösung in hinsicht auf Schnelligkeit, Speicherbedarf,.. und warum?

1) Vergiss das ganz schnell wieder. Kümmer dich nicht drum.

warum?? Haben solche Betrachtungen keine Auswirkung auf Performance? Bei nur einer Variable, klar spielt es keine rolle. Aber bei langen Schleifen?? Ich bin auch Javaanfänger und Frage mich was speichertechnisch günstiger ist.

Variante 1

String foo = "";

for(int n = 0 ; i< dreimalundendlich :-) ; i++){
      foo = irgendwas()
}

oder Variante 2

for(int n = 0 ; i< dreimalundendlich :-) ; i++){
     String foo  = irgendwas()
}

Sagen wir noch, dass der String foo außerhalb der schleife nicht mehr gebraucht wird.
Bei Variante 1 wird der Speicherplatz doch nur einmal belegt und dann überschrieben.
Bei Variante 2 werden dreimalunendlich wiele Strings erzeugt oder nicht? Und unendlich ist schon groß aber dreimal?? Wieviel kostet eigentlich unendlich viel RAM??

Ich hoffe ihr könnt die schlechten Witze vertragen, die Frage ist schon ernst gemeint.

 

[faetzminator]

M_Schaffrath hat alles dazu gesagt. Lege den Scope der Variablen immer nur so klein fest, wie notwendig.
Wenn du aber irgendwann je irgendwo in einem deiner Programme Performance- oder Speicherprobleme haben wirst, kann man für das konkrete Problem eine Lösung suchen. Aber normalerweise wurde einfach irgendein Algorithmus schlecht implementiert. Ob man nun Variablen da oder da deklariert, ist grundsätzlich wurst.

Sagen wir noch, dass der String foo außerhalb der schleife nicht mehr gebraucht wird.

Dann wird er innerhalb der Schleife deklariert.

Bei Variante 1 wird der Speicherplatz doch nur einmal belegt und dann überschrieben.

Das ist nur eine Variable mit einer Referenz auf einen String.

Bei Variante 2 werden dreimalunendlich wiele Strings erzeugt oder nicht? Und unendlich ist schon groß aber dreimal?? Wieviel kostet eigentlich unendlich viel RAM??

Strings hast du genau gleich viele. Irgendwie hats hier viel zu viele "unendlich" in deinen Fragen. Ich weiss echt nicht, auf was du hinaus willst. Vergiss das Thema einfach ganz schnell wieder 😉

 

[M_Schaffrath]

Du hast aber keine Ahnung, was der Java-Compiler und der Garbage Collector mit deinem Code anfangen und ob das tatsächlich alles so ausgeführt wird, wie du es hinschreibst. Und bis deine Anweisungen irgendwas im Speicher oder im Prozessor tun, passieren noch allerlei Dinge, über die du null Kontrolle hast. In der Praxis spielt das auch eigentlich selten eine Rolle.

Gerade als Anfänger sollte man sich eher darauf konzentrieren, aufgeräumten, lesbaren Code zu schreiben, als versuchen zu wollen, schlauer als der Compiler zu sein.

 

[Landei]

Die JVM merkt bei der zweiten Variante, dass sie den Speicherbereich für foo bei jedem Durchlauf wiederverwenden kann. Insgesamt ist das Ding ziemlich clever. Spekulationen über die Performance sind sinnlos, für eine Einschätzung helfen nur zwei Dinge: Geschwindigkeit messen (und aussagekräftige Benschmarks zu schreiben ist ziemlich schwierig) oder den Bytecode anschauen - und selbst das ist nicht hundert Prozent sicher (wegen unterschiedlicher VMs oder unterschiedlichen Optimierungseinstellungen).

Nur mal als Beispiel, was da hinter den Kulissen abgeht: Mein Kollege hat neulich einen Bug gesucht: Der Code lief bei ihm, aber nicht auf dem Server. Der Unterschied war, dass ein [c]long getId() { return super.getId(); }[/c] auf dem Server komplett wegoptimiert wurde (worauf aber mit Reflection zugegriffen wurde).

 

[vonAltmann]

OK, danke für die vielen antworten und sorry an den Threadersteller, das ich deinen Beitrag missbraucht hab. Die Frage die ich hatte hat sich geklärt. Ich kann mich also schon darauf verlassen, dass der GC bzw. VM clever genug sind um auf solche sachen zu achten. Ich habe, bevor ich mit Java angefangen habe, Microcontroller mit Assembler programmiert. Diese Teile haben extrem wenig speicher. So ein bischen mehr als Null halt 🙂 Da war jedes Byte wichtig.