Warum Delphi 64-Bit-IDE

[win568]

Hi

Also wir würden dringendst eine 64 Bit IDE benötigen. Der Umfang unseres Projektes sprengt derzeit fast die IDE.
Laden des Projektes und einmal Compilieren und 4GB erreicht. Neustart, nochmal compilieren und es geht mal gerade so (3,7 GB virtueller Speicherverbrauch). Und ja, bevor jemand da zum Belehren anfängt, wir haben unser Projekt bereits in Packages
aufgeteilt (95 Stück an der Zahl). Leider ist hier die Unterstützung der IDE Funktionen (CodeInsight, ErrorInsight, CodeCompletion usw.) mehr als Mangelhaft, weshalb ich lieber noch mit dem Monolithen arbeite. Dort funktionieren die genannten Funktionen
interessanterweise.

[himitsu]

Zitat von win568:

wir haben unser Projekt bereits in Packages aufgeteilt (95 Stück an der Zahl)

Jo, unmengen an Packages und DLLs, die nicht alle bei Programmstart geladen werden, sondern erst wenn benötigt,
aber die komplette Projektgruppe auf einmal kompilieren, naja ...

Zitat von himitsu:

Problem ist auch, dass der Inline-Compiler gern ein Speicherleck hat.
Nja, nicht direkt Leck ... beim gleichzeitigen beim Kompilieren mehrerer Projekte, wird der Cache erst am Ende geleert, was ihn vorher gern mal volllaufen lässt.

[jbg]

Zitat von himitsu:

aber die komplette Projektgruppe auf einmal kompilieren, naja ...

Bei vielen Packages sind dann viele Units mehrfach im Speicher des Compilers und im Speicher von ErrorInsight. Der Compiler hält für jedes Projekt der Projekgruppe eine eigene Kopie der genutzten Units, unabhängig ob sie explizit ("uses MyUnit in 'MyUnit.pas'") oder implizit (uses YourUnit) eingebunden sind.


Package A:
- Unit A1
- Unit A2

Package B:
- requires A
- Unit B1: uses A1, A2
- Unit B2

EXE-Projekt:
- Runtime Packages: A, B
- Unit C1 uses B1, B2
- Unit C2


Das führt beim Kompilieren und beim CodeInsight zu folgenden Units im Speicher:
- Package A: (SysInit, System, A1, A2)
- Package B: (SysInit, System, A1, A2, B1, B2)
- EXE-Projekt: (SysInit, System, A1, A2, B1, B2, C1, C2)

Und das ganze zwei Mal, da ErrorInsight auch noch alle expliziten Units im Speicher hält.


Wenn man das auf mehrere Packages hochrechnet, dann sieht man recht schnell das Ende des virtuellen Adressraums.


Es wird interessant was bei Delphi 10.4 mit seinem LSP Server herauskommt. Ob pro Projekt ein eigener Prozess läuft oder die Prozesse nur für unterschiedlichen Aufgaben (ErrorInsight, CodeInsight) zuständig sind und man nur ein wenig mehr "Luft" wegen der Aufsplittung hat. Der LSP Server ist ja laut TaskManager-Screenshot immernoch 32Bit.

[win568]

Hi Andi

Wäre natürlich wieder zu viel zu erwarten gewesen, dass Emba hier einen 64 Bit LSP Server spendiert hätte. Das hätte auf jeden Fall das Problem entschärft.

Habe mir die Beta schon installiert, aber derzeit funktioniert bei unseren Projekten keine der genannten Funktionen. Werde mal auf die nächste Version warten

[Daniel]

Zitat von win568:

Wäre natürlich wieder zu viel zu erwarten gewesen, dass Emba hier einen 64 Bit LSP Server spendiert hätte. Das hätte auf jeden Fall das Problem entschärft

Nachdem 64 Bit ihn nicht schneller gemacht hätten, kann es nur um die Menge an verfügbarem Speicher gehen. Inwiefern sollte ihn die 32 Bit Architektur in dieser Hinsicht ausbremsen? Auch bei umfangreichen Projekten liegt dessen Speicherverbrauch weit unterhalb jeglicher Limits. Welches Problem also würde jetzt durch die 64 Bit Architektur konkret entschärft?

[win568]

Hi Daniel

In unserem Fall das Speicherproblem. Ein 32Bit Prozess kann maximal 4GB Speicher belegen. Wie Andi ja bereits beschrieben hat, wird das Problem mit den Packages potenziert. Daher wäre hier eine vorausschauende Entscheidung gewesen, den LSP Server Dienst unter 64Bit zu bauen.

Damit bei uns die Windows Entwicklung funktioniert, räume ich Delphi aus. Alle nicht für 32/64Bit benötigten Known IDE Packages werden entfernt. Damit gewinnt man schon mal 400 MB an virtuellem Speicher. Wir haben eigen Experts entwickelt, die sowohl Packages als auch Monolithen "Out of Delphi" compilieren können. Der Grund darin liegt, dass Delphi bei Erzeugen anscheinend mit Speicherlecks zu kämpfen hat. Beim Erzeugen geht der Speicher über 4GB, starte ich neu und führe es erneut aus, werden die restlichen Units dazucompiliert und der Speicher bleibt unter 4GB. Mit dem "Out of Delphi" erzeugen funkt es auch so.

[Sherlock]

Also zugunsten einer Komfortfunktion (Projektgruppe) verzichtet Ihr auf alles andere? Das spricht dann doch viel eher dafür, lieber mal die Gruppe zu entkrauten und auf andere Technologien wie Jenkins zu setzen.

Sherlock

[jaenicke]

Zitat von win568:

Wir haben eigen Experts entwickelt, die sowohl Packages als auch Monolithen "Out of Delphi" compilieren können.

Dafür gibt es auch ein Häkchen in den Projektoptionen, dass msbuild extern verwendet werden soll.

Zitat von win568:

Hmm. Welche Komfortfunktion ?? Die Packages bauen aufeinander auf. Dadurch sind diese in einer Gruppe zu halten, da viele Programmierer an unterschiedlichen Dateien arbeiten und einchecken. Mit dem nächsten Svn Abgleich müssen teilweise die Packages wieder neu erzeugt werden.

Dafür braucht man aber keine Projektgruppe mit allen Packages. Bei uns ist das z.B. unterteilt in die Packages mit gemeinsamen Units und Komponenten, die von den verschiedenen Projekten für Anwendungen und DLLs dann verwendet werden. Diese Packages werden per Kommandozeile installiert und mit msbuild erzeugt.

Beim Debuggen usw. haben wir dann nur die Projektgruppe oder das Einzelprojekt offen, an dem wir konkret arbeiten.

Würden wir das anders machen, hätten wir insbesondere bei Versionen wie XE6 deutliche Probleme gehabt. So funktionierte es selbst da schon recht gut und in den 10er Versionen haben wir so gut wie gar keine Probleme mehr damit.

Zitat von himitsu:

PS: Die eine alte Funktion von Delphi ist echt saublöd.
"Automatisch speichern beim Kompilieren" speichert nach dem erfolgreichen Kommpilieren, also erst nachdem Delphi abgestürzt ist, und somit war dann alles futsch.

Man sieht bereits beim Kompilieren, dass sich der Speicherknopf deaktiviert. Das Speichern passiert vor dem Kompilieren.

Zitat von himitsu:

Auch wird der "Desktop" nicht gespeichert (XE), wenn man "Speichert", sondern erst wenn man Delphi schließt.

Das stimmt. Das hat aber den Vorteil, dass es bei Abstürzen durch eine bestimmte offene Unit oder ein Projekt nicht gleich beim Start wieder einen Absturz gibt.