Liegen lokale Klassen auf dem Stack?

[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....