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.