Delphi 7 Win32 Speicherbelegung über 500MB

[Kurti06]

Hallo,
ich habe von der Speicherverwaltung von Delphianwendungen leider nicht sehr viel eigenes Wissen.
Darum bitte ich euch mir zu helfen.
Wir haben eine Delphi 7 win32 EXE zusammengesetzt, die sehr große Listen erstellt.
Der belegte Arbeitsspeicher läuft laut Taskmanager bis 5oo MB hoch,
dann bricht das Proggi mit 'zu wenig Arbeitspeicher' ab.
Dies auf WinXP und Win2003 ohne Bezug auf den phys.o.virtuellem Arbeistpeicher.
Darum meine Vermutung es gbt irgend welche Grenzen, die ich nicht kenne.

Gibt es Einschränkungen in der Art ? Wie kann man dies umgehen, oder wie kann der Anwendung mehr Speicher
zuordnen?

Danke und Grüße - Kurti

[Christian Seehase]

Moin Kurti,

erst einmal herzlich willkommen hier in der Delphi-PRAXiS.

Ich hatte auch schon mal ein Programm, dass sich Hauptspeicher in der genannten Grössenordnung genehmigt hat, dies allerdings ohne abzubrechen (auch D7).
Auch wenn es nicht unmöglich ist solchen Speicherverbrauch "regulär" zu erreichen, könntest Du das Programm mal mit MemProof prüfen, ob Du Dir nicht irgendwo Speicherlecks eingehandelt hast, die zu dem Problem führen.

[EDIT]
Sollte alles OK sein...
Mehr als 2GB (mit "Trick" evtl. 3GB) Adressraum bekommt die Anwendung auch mit virtuellem Speicher nicht.
Ggf. müsstest Du die Daten dann auch auslagern (z.B. vielleicht via Memory Mapped File / MMF)
[/EDIT]

[Kurti06]

Danke für die Begrüßung,
ja Speicherlecks hab ich schon gesucht.
Sind keine und es ist auch nachzurechnen, dass so viel Speicher verbraucht wird.
Ich kann da auch nicht schnell was anders machen, da die Formulare sehr wichtig und tief eingebunden sind.

Drum halt die Frage wie kann ich es bewerkstelligen, das nicht pünktlich nach 500 MB das Proggi mit Meldung aufhört.
Gibt es Compilereinstellungen ?
Kann man dem Betriebsystem nicht sagen 'ich werde min. soviel Speicher verbrauchen'?

Gruß Kurti

[mkinzler]

Zitat:

Drum halt die Frage wie kann ich es bewerkstelligen, das nicht pünktlich nach 500 MB das Proggi mit Meldung aufhört.

Da Chris gesagt hat, daß es nicht an D7 liegen kann, mußt du die wirkliche Ursache für das Problem suchen.

Zitat:

Kann man dem Betriebsystem nicht sagen 'ich werde min. soviel Speicher verbrauchen'?

Du kannst im Programm Speicher auf Vorrat anfordern (machen manche Programme). Nur ob das dir hilft, würde ich bezweifeln (eher erschweren).

Was sind das für Formulare, daß sie so viel Speicher benötigen? Vielleicht solltest du was an der Lebensdauer der Formualre ändern (dynamsiches erzeugen und Freigeben)

[Bernhard Geyer]

Wenn du keine Speicherlücken hast so rauscht Du vermutlich voll in das Fragmentierungsproblem des Default-Memory-Manager von Delphi bis D2005. D2006 hat hier mit FastMM einen neuen Memory-Manager welche folgende Vorteile hat:

- I.d.R. schneller
- Bei weiten geringere Gefahr von Speicherfragmentierung
- Eingebauter, aktivierbarer MemChecker
- Verwendung von Strings in Exe und DLL ohne SharMem.DLL
- Verwendung bis 3GB als 32-Bit-Programm unter 64-Bit Windows
- ...

Schau dir einfach mal den Artikel auf BDN an

[Christian Seehase]

Moin Kurti,

Zitat von Kurti06:

... da die Formulare sehr wichtig und tief eingebunden sind.

werden die statisch oder dynamisch erzeugt?
Falls FastMM nichts nutzt, oder Du es nicht benutzen kannst/darfst, wäre es nämlich vielleicht eine Möglichkeit den Platzbedarf durch dynamisches Erzeugen der Formulare zu verringern (obwohl dann ja auch die Fragmentierung sich wieder erhöhen könnte )

[EDIT]
@Bernhard:
Auch unter Win32 (z.B. XP-Pro, Windows 2003) können Anwendungen 3GB mit FastMM nutzen
(gemäss Doku zu Version 4.72 vom 24.09.2006)
[/EDIT]

[Bernhard Geyer]

Zitat von Christian Seehase:

Falls FastMM nichts nutzt, oder Du es nicht benutzen kannst/darfst, wäre es nämlich vielleicht eine Möglichkeit den Platzbedarf durch dynamisches Erzeugen der Formulare zu verringern (obwohl dann ja auch die Fragmentierung sich wieder erhöhen könnte )

Dann dürften aber eher die GDI-Ressourcen ausgehen was auch einen anderen Fehler bringt.

Zitat von Christian Seehase:

Auch unter Win32 (z.B. XP-Pro, Windows 2003) können Anwendungen 3GB mit FastMM nutzen
(gemäss Doku zu Version 4.72 vom 24.09.2006)

Ok. Hatte aber (in älterer Version) gelesen das dies nur unter Win64 der Fall währe da AFAIK unter Win32 die Aufteilung des verfügbaren Adressspeichers 2 GB Anwendung, 1 GB für System-"Einblendungen" und 1 GB für HW-"Einblendungen" wäre.
Aber gut zu wissen. Bisher konnten wir immer durch bessere Architektur/Algorithemn/Strukturen meistens dieses Problem "umschiffen".

[Christian Seehase]

Moin Bernhard,

Zitat von Bernhard Geyer:

Dann dürften aber eher die GDI-Ressourcen ausgehen was auch einen anderen Fehler bringt.

bei einem non-VCL-Programm stimmt das wohl, aber bei Verwendung der VCL werden ja beim Erzeugen des Formulares Objekte erzeugt, für die Speicher angefordert wird. Es wäre also Beides möglich.
Was das Problem mit den GDI-Resourcen angeht:
Ich erinnere mich an eine Komponentensammlung, bei der man bei Inaktivität von Windows-Komponenten (TWinControl-Nachfahren) die Handles wieder freigeben konnte, um solche Probleme zu vermeiden.

[Union]

Zitat:

Wir haben eine Delphi 7 win32 EXE zusammengesetzt, die sehr große Listen erstellt.

Wozu dienen diese Listen? Und was ist darin enthalten? Vielleicht ist es ja auch ein Designproblem und man könnte die Aufgabe ganz anders lösen...