Liegen lokale Klassen auf dem Stack?

[Bjoerk]

Beispiel Test class:

Delphi-Quellcode:

procedure TSomeClass.DoSomeThing;
var
  Test: TTest;
begin
  try
    Test := TTest.Create; // <-
    ..
  finally
    Test.Free;
  end;
end;

[himitsu]

Natürlich nicht.

Nur die Variable für den Instanzzeiger liegt auf dem Stack. (also nur der Pointer)

[Neutral General]

Warum fragst du denn? Bin neugierig.

[Namenloser]

Zitat:

Zitat von himitsu (Beitrag 1388228)

Natürlich nicht.

Ist nicht so „natürlich“. In C++ geht das nämlich durchaus.

[Neutral General]

Zitat:

Zitat von Namenloser (Beitrag 1388234)

Zitat:

Zitat von himitsu (Beitrag 1388228)

Natürlich nicht.

Ist nicht so „natürlich“. In C++ geht das nämlich durchaus.

Und wo sonst noch? Und wer benutzt/macht das?
Ich denke C++ ist in der Hinsicht eher "unnatürlich".

[Stevie]

Zitat:

Zitat von Namenloser (Beitrag 1388234)

Zitat:

Zitat von himitsu (Beitrag 1388228)

Natürlich nicht.

Ist nicht so „natürlich“. In C++ geht das nämlich durchaus.

Jo, dann rufste aber nich new auf.

[Bjoerk]

Ok. Vielen Dank.

[Namenloser]

Zitat:

Zitat von Neutral General (Beitrag 1388237)

Zitat:

Zitat von Namenloser (Beitrag 1388234)

Zitat:

Zitat von himitsu (Beitrag 1388228)

Natürlich nicht.

Ist nicht so „natürlich“. In C++ geht das nämlich durchaus.

Und wo sonst noch? Und wer benutzt/macht das?
Ich denke C++ ist in der Hinsicht eher "unnatürlich".

Mir fällt unter den objektorientierten Sprachen nur C++ ein. Aber wenn man in nicht-objektorientierten Sprachen objektorientiert programmiert, ist das gar nicht ungewöhnlich. Records liegen in Delphi ja auch auf dem Stack.

Wer das benutzt: Ich benutze das so oft es geht, weil Stack-Allokationen schneller sind als Heap-Allokationen. Sehr nützliches Feature meiner Meinung nach. Es geht dabei ja nicht nur um den Stack, sondern auch um geschachtelte Konstrukte, also beispielsweise Objekte, die wieder andere Objekte enthalten. Hier muss man nur einmal Speicher reservieren statt mehrfach und spart sich eine ganze Reihe von Pointern.

[Neutral General]

Zitat:

Zitat von Namenloser (Beitrag 1388240)

Wer das benutzt: Ich benutze das so oft es geht, weil Stack-Allokationen schneller sind als Heap-Allokationen. Sehr nützliches Feature meiner Meinung nach. Es geht dabei ja nicht nur um den Stack, sondern auch um geschachtelte Konstrukte, also beispielsweise Objekte, die wieder andere Objekte enthalten. Hier muss man nur einmal Speicher reservieren statt mehrfach und spart sich eine ganze Reihe von Pointern.

In meinen Augen ist der Stack nicht dazu gedacht dort komplette komplexe Objekte abzulegen.
Das kann je nachdem auch ganz schnell in die Hose gehen bei Rekursionen oder einer großen Menge Objekte.
Der Stack ist im Vergleich zum Heap winzig.

[Zacherl]

Zitat:

Zitat von Neutral General (Beitrag 1388243)

Zitat:

Zitat von Namenloser (Beitrag 1388240)

Wer das benutzt: Ich benutze das so oft es geht, weil Stack-Allokationen schneller sind als Heap-Allokationen. Sehr nützliches Feature meiner Meinung nach. Es geht dabei ja nicht nur um den Stack, sondern auch um geschachtelte Konstrukte, also beispielsweise Objekte, die wieder andere Objekte enthalten. Hier muss man nur einmal Speicher reservieren statt mehrfach und spart sich eine ganze Reihe von Pointern.

In meinen Augen ist der Stack nicht dazu gedacht dort komplette komplexe Objekte abzulegen.

Ansichtssache :P Ich sehe das wie Namenloser. Die Performance ist deutlich besser und in C++ ist das Konzept durchaus schlüssig, wenn man andere Kriteren wie RAII, Referenzen, Copy & Move Semantics miteinbezieht. Man kann natürlich auch jederzeit Objekte auf dem Heap anlegen, wenn man die Befürchtung hat, dass der Stack zu klein ist - macht man allerdings nur in Ausnahmefällen oder bei Containerklassen.

[Neutral General]

Damit der Performanceunterschied groß genug ist um ihn zu merken muss es aber entweder um große Mengen von Objekten gehen (Achtung, es wird eng auf dem Stack!) oder die Prozedur wird sehr oft in sehr kurzer Zeit aufgerufen, sodass sich der Unterschied irgendwann aufsummiert und bemerkbar wird.

[Zacherl]

Zitat:

Zitat von Neutral General (Beitrag 1388246)

Damit der Performanceunterschied groß genug ist um ihn zu merken muss es aber entweder um große Mengen von Objekten gehen (Achtung, es wird eng auf dem Stack!) oder die Prozedur wird sehr oft in sehr kurzer Zeit aufgerufen, sodass sich der Unterschied irgendwann aufsummiert und bemerkbar wird.

Reicht schon, wenn du eine Hand voll Objekte bei jedem Aufruf erstellst und am Ende wieder freigibst (wobei man fairer Weise sagen muss, dass der Delphi Memory Manager ja zumindest schonmal versucht die Context Switches in den Kernel zu minimieren, indem ganze Pages reserviert und "per Hand" verwaltet werden; dennoch ist die Verwaltung eines Heaps ein ziemlicher Overhead). Dass Performanceunterschiede erst bei einer gewissen Laufzeit relevant werden, ist ja eine generelle Tatsache.

[Namenloser]

Wenn mir auf dem Stack der Platz ausging, dann war daran in den rund 15 Jahren, die ich mittlerweile programmiere, immer eine zu hohe Rekursionstiefe schuld. Nie lag es daran, dass ein Objekt zu groß war.

[Neutral General]

Bin mir zu 99% sicher, dass jeder Heap so arbeitet und sich anfangs erstmal einen Vorrat an Memory Pages vom Kernel anfordert den er dann selbst verwaltet.
Also switches zum Kernel sollten auch beim Heap relativ selten sein. Und je nachdem wie der Heap verwaltet wird ist das Anfordern oder/und (?) Freigeben von Speicher sogar O(1).

Klar ist es immer noch aufwendiger als grad den Stackpointer zu verschieben aber auch nicht so viel aufwendiger dass es außerhalb von Extrem- bzw- Spezialfällen keinen nennenswerten Unterschied machen sollte.

Zitat:

Wenn mir auf dem Stack der Platz ausging, dann war daran in den rund 15 Jahren, die ich mittlerweile programmiere, immer eine zu hohe Rekursionstiefe schuld. Nie lag es daran, dass ein Objekt zu groß war.

An einem (1) Objekt wird es sicher nicht scheitern (es sei denn es ist gigantisch). Aber was ist mit 100 Objekten? Und gerade bei Rekursion kommst du deutlich schneller an deine Grenzen wenn du statt 20 Bytes (als Beispiel einer Funktion ohne Objekte auf dem Stack und mit ein paar ints/pointern/etc als lokale Variablen) auf einmal 200 Bytes oder sogar mehr pro Aufruf auf den Stack packst. Dann ist 10x schneller Schluss und wo man im Normalfall nur bei versehentlichen Endlos-Rekursionen einen Stackoverflow bekommt, kann das dann vllt. schon in Fällen auftreten wo auf dem Papier keine Endlosrekursion vorlag, aber die Rekursion sehr tief ging und der Stack einfach voll war.

[Namenloser]

Zitat:

Zitat von Neutral General (Beitrag 1388251)

An einem (1) Objekt wird es sicher nicht scheitern (es sei denn es ist gigantisch). Aber was ist mit 100 Objekten? Und gerade bei Rekursion kommst du deutlich schneller an deine Grenzen wenn du statt 20 Bytes (als Beispiel einer Funktion ohne Objekte auf dem Stack und mit ein paar ints/pointern/etc als lokale Variablen) auf einmal 200 Bytes oder sogar mehr pro Aufruf auf den Stack packst. Dann ist 10x schneller Schluss und wo man im Normalfall nur bei versehentlichen Endlos-Rekursionen einen Stackoverflow bekommt, kann das dann vllt. schon in Fällen auftreten wo auf dem Papier keine Endlosrekursion vorlag, aber die Rekursion sehr tief ging und der Stack einfach voll war.

Aber dann ist meiner Meinung auch der Punkt erreicht, wo man über das Design seines Codes nachdenken sollte und die Rekursion z.B. durch einen manuellen Stack ersetzen sollte. Denn man will ja auch nicht, dass einem der Code plötzlich um die Ohren fliegt, nur weil mal die Eingabe 10x so groß ist. Ich achte immer darauf, dass der Hardwarestack höchstens logarithmisch zur Eingabe wächst (O log n), denn so ist er auch gedacht. Solange man das beachtet, hat man eigentlich nie ein Problem. Ich habe das zumindest noch nie erlebt.

[Stevie]

Nur mal 2 Begriffe in den Raum geworfen (pro stack objects): Multithreading und data locality

[himitsu]

Wenn man unbedingt will, dann kann auch im Delphi eine Klasse auf den Stack.
Siehe NewInstance und FreeInstance, wo man die Speicherverwaltung ändern müsste.

Aber da ist es dann einfacher einen Record zu verwenden.

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1388255)

Wenn man unbedingt will, dann kann auch im Delphi eine Klasse auf den Stack.
Siehe NewInstance und FreeInstance, wo man die Speicherverwaltung ändern müsste.

Jo, genau und wenn sie nicht innerhalb der Routine wieder freigibst, zerschießt du dir den Stack, Klasse Idee ;)

[himitsu]

Die ist doch lokal, also muß sie sowieso am Ende weg.
Automatisch freigegeben wird also so oder so der Speicher, aber Referenzen innerhalb der Klasse (z.B. Strings) schwirren dann als Speicherleck im Heap rum.

Wer unbedingt sowas machen will, der hat dann halt gefälligst auch bissl aufzupassen. :stupid:

[Fritzew]

Es gab (oder gibt sogar noch) das gute alte object..... "TurboVision"
Also sowas wie

Delphi-Quellcode:

type tmyObject = object
end;

Das konnte man auf dem Stack benutzen.
Habe gerade eine Anwendung sortiert die das noch benutzt hat..
"Gute alte Zeit", Handbücher die einen halben Meter dick waren aufeinander gestapelt....

[QuickAndDirty]

Stack Allocation scheint ziemlich praktisch zu sein, besonders wenn man hunderte Objekte hat.
So liegen Beispielsweise alle Items eines VCL TStringgrids auf dem Stack. Die Struktur hinter Cells[col, row] und Objects[col, row] ist eine Objekt vom typ TStringGridStrings.
TStringGridStrings verschiebt einfach den Basepointer des Stacks wenn Collcount oder Rowcount erhöht werden.
Ist mit Stack Allocation das manipulieren des BP Registers gemeint gemeint? oder ist das wieder was anderes?

[Neutral General]

Zitat:

Zitat von QuickAndDirty (Beitrag 1388271)

So liegen Beispielsweise alle Items eines VCL TStringgrids auf dem Stack. Die Struktur hinter Cells[col, row] und Objects[col, row] ist eine Objekt vom typ TStringGridStrings.

Das ist unmöglich. Für Daten die auf dem Stack abgelegt werden gibt es nach der aktuell laufenden Prozedur keine Garantie dass diese nicht überschrieben werden.
Eher im Gegenteil: Die Daten werden mit ziemlicher Sicherheit früher oder später überschrieben.
Dazu kommt noch, dass man den Speicher auf dem Stack am Ende einer Prozedur freigeben muss oder man zerschießt sich den Stack. Das ist aus so vielen Gründen nicht möglich und Unsinn.

Lokale Variablen kann man durchaus auf dem Stack ablegen, auch ganze Objekte (wie man dazu steht ist natürlich ein anderes Thema :P ) aber nichts auf dem Stack überlebt den aktuellen Stackframe.

[Stevie]

Es geht in dem Blog zwar um C++ und Spieleentwicklung, aber die technischen Informationen lassen sich auch in Delphi übertragen:
http://ithare.com/c-for-games-perfor...data-locality/

BTW, jeder unnötige string (vor allem die impliziten, die man so gar nicht mitbekommt) ist auch eine Heapallokierung.
Von daher macht es schon Sinn, diesbezüglich ein bisschen Bescheid zu wissen und sensibel zu sein.

Anekdote: Ich habe jüngst einen Rot-Schwarz-Baum implementiert. Die ursprüngliche Implementierung nutzte für die Knoten Objekte.
Einfach zu implementieren und man konnte schön Vererbung nutzen (TRedBlackTreeNode<T> <- TRedBlackTreeNode <- TBinaryTreeNode).
Das sorgte allerdings für elendigen Speicheroverhead durch den ganzen Klump, der bei Objekten so mit kommt.
Also lieber Records/Pointer - erste Implementierung mit New/Dispose. Weniger Speicher - gut.
Aber über Zeit Memoryfragmentierung (übrigens genauso wie bei Objekten) und somit zunehmende Cache misses.
Also den Speicher für die Records aus einem Array nehmen, so dass eine bessere Lokalität gegeben ist.