Frage von xXxXx123xXxXx, 59

Nehmen die Variablen in C# Arbeitsspeicher?

Hallo :) Ich hab mal ne Frage: wenn ich jetzt zum Beispiel einen Integer und einen Int32 benutze, verbrauchen diese Variablen dann Arbeitsspeicher?

Antwort
von sarahj, 31

ja im allgemeinen schon.
je nach Art der Variablen mehr oder weniger temporär (statisch, heap, stack).
Bei boxed typen sogar zweimal: die Variable selbst, die ja eine Referenz (=Zeiger) auf ein Objekt hält, welches den eigentlichen Wert hält.

Manche (lokale) kann der Compiler auch wegoptimieren, so daß die Werte lediglich in Registern gehalten werden. Das kommt aber sehr auf Compiler/Jitter + Debugging Optionen an...

zu boxing, siehe:
https://msdn.microsoft.com/en-us/library/yz2be5wk.aspx

Antwort
von NoHumanBeing, 29

Ja.

Lokale Variablen liegen auf dem Stack. Variablen, die zu einer Datenstruktur (z. B. Klasse) gehören, machen jedes einzelne Objekt größer. Die Objekte liegen auf dem Heap.

Kommentar von EightSix ,

Das hat wenig mit dem Gültigkeitsbereich der Variable sondern mehr mit dem Art (referenzieller oder einfacher Datentyp). Strukturen sind übrigens nicht referenziell (außer bei boxing oder als Member einer Klasse), dein 2. Satz ist also auch falsch.

Worauf du hinaus willst ist wohl das was ich im 1. Satz schrieb.

Kommentar von NoHumanBeing ,

Das hat wenig mit dem Gültigkeitsbereich der Variable sondern mehr mit dem Art (referenzieller oder einfacher Datentyp).

[..] dein 2. Satz ist also auch falsch.

Nein, da irrst Du!

Auch wenn ich einen einfachen Datentyp ("Wertetyp") in ein Objekt packe, liegt er (innerhalb des Objekts) natürlich auf dem Heap. Er steht allerdings im Gegensatz zu einem Referenztyp tatsächlich als Wert innerhalb des Objekts, während bei einem Referenztyp tatsächlich nur ein Pointer auf den eigentlichen Wert innerhalb des Objekts stehen würde.

Objektattribute liegen also immer auf dem Heap, auch wenn es sich um einfache Datentypen handelt.

Das einzige, was auf dem Stack liegt, sind lokale Variablen. Bei Wertetypen liegt hierbei unmittelbar der Wert auf dem Stack. Bei Referenztypen liegt ein Pointer auf den Referenztyp (also letztlich eine Adresse) auf dem Stack.

Objektvariablen hingegen liegen immer auf dem Heap und zwar unabhängig davon, ob sie von einem Referenz- oder Wertetyp sind. Der Unterschied liegt darin, dass an der Stelle, an der die Objektvariable (auf dem Heap) liegt, entweder unmittelbar der Wert (bei Wertetypen) oder eben ein Pointer auf einen anderen Heapbereich (bei Referenztypen) hinterlegt ist.

Die Runtime von .NET wird übrigens auch nicht einzelne Bytes an Speicher allozieren, sondern immer größere zusammenhängende Blöcke. Ob Du ein paar ints mehr oder weniger in einer Funktion verwendest, macht daher meist keinen Unterschied vom Speicherbedarf her, den die Runtime durch das Betriebssystem decken lässt und somit auch nicht der Menge Speicher, die sie anfordert, es sei denn, der Callstack wird sehr tief (z. B. bei tiefer Rekursion).

Antwort
von Omnivore08, 10

Natürlich verbrauchen die Speicher! Sie liegen im Datensegment des Prozesses. In C nannte man die Speicheranforderung "allokieren". Damit wird Speicher angefordert!

Kommentar von NoHumanBeing ,

Sie liegen im Datensegment des Prozesses.

Die meisten Variablen liegen entweder auf dem Stack oder auf dem Heap.

Im Datensegment (".data" in Assembler) liegen nur globale Variablen, die es in vielen modernen Programmiersprachen überhaupt nicht mehr gibt.

Das Layout sieht so aus.

https://upload.wikimedia.org/wikipedia/commons/7/70/Typical_computer_data_memory...

"Text" ist der Programmcode (obwohl das Segment "Text" heißt natürlich in Maschinensprache, nicht in Quelltext), "Heap" ist alles, was zu "Objekten" gehört (in C alles, was mit "malloc" alloziert wird) und "Stack" sind die lokalen Variablen und Rücksprungadressen.

"Uninitialized data (BSS)" und "Initialized data" wird in Sprachen wie C-Sharp oder Java, die keine "globalen Variablen" erlauben, überhaupt nicht mehr verwendet, hat also im Grunde die Länge Null. C hinterlegt dort "globale Variablen", also solche, die außerhalb von Funktionen definiert wurden. Lokale Variablen, die in Funktionen definiert wurden, liegen auf dem Stack. Alles, was mit "malloc" alloziert wurde, liegt auf dem Heap.

Kommentar von Omnivore08 ,

Mhh okay....danke für die Info....kenn das da nur aus dem Assembler. Dass das in den Compilern heute anders Läuft kann schon sein.

Was wäre mit statischen Variablen in statischen Klassen? Das wäre doch sowas wie "global" ^^

Wozu der Stack da ist, ist mir schon klar ^^

Kommentar von NoHumanBeing ,

Leider kann ich nicht sagen, wo JVM oder CLR statische Variablen hinterlegen. Vermutlich auch auf dem Heap.

In Java oder C-Sharp läuft ja nicht "das Programm" direkt auf dem Prozessor, sondern es läuft die JVM oder die CLR und die interpretiert dann das Programm (oder JIT-ted es teilweise).

Wären Java oder C-Sharp compilierte Sprachen, könnten die entsprechenden Daten in ".data" liegen. Aber letztlich sind es ja Daten für die JVM oder die CLR und die werden vermutlich auch auf dem Heap liegen. Die JVM wird vermutlich ein entsprechendes "malloc()" machen, wenn sie das Programm, das sie ausführen soll (das für sie ja Daten sind, kein Code, nachdem es sich nicht um ein Maschinenprogramm handelt) geladen und dekodiert hat. Das ist aber lediglich eine (plausible) Vermutung. (Soll heißen: Ich kenne die interne Funktionsweise der JVM/CLR nicht so genau.)

Der Stack der JVM muss auch nicht tatsächlich auf dem "Prozessor-Stack" liegen. Vermutlich liegt er eher auf dem Heap. ;-) Der "Prozessor-Stack" steuert ja schließlich die Ausführung der JVM selbst, nicht jedoch die Ausführung des Java-Programms.

Aber ich schätze das trägt eher zur Verwirrung, als zur Beantwortung bei. :-P

Kommentar von Omnivore08 ,

lol...hehe ja nee danke. Soweit ist mir das dann  auch größtenteils bekannt. Das andere ist (wie du auch sagst) Vermutung.

Trotzdem Danke für den Beitrag :-)

Antwort
von Schachpapa, 24

Ja, aber der ist dann nicht weg, du kriegst ihn spätestens bei Programmende zurück.

Keine passende Antwort gefunden?

Fragen Sie die Community