AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Warum Delphi 64-Bit-IDE

Ein Thema von freimatz · begonnen am 7. Mai 2020 · letzter Beitrag vom 8. Mai 2020
Antwort Antwort
Seite 3 von 4     123 4   
jbg

Registriert seit: 12. Jun 2002
3.466 Beiträge
 
Delphi 10.1 Berlin Professional
 
#21

AW: Warum Delphi 64-Bit-IDE

  Alt 7. Mai 2020, 19:45
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.
  Mit Zitat antworten Zitat
win568

Registriert seit: 8. Sep 2008
100 Beiträge
 
#22

AW: Warum Delphi 64-Bit-IDE

  Alt 7. Mai 2020, 19:51
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
  Mit Zitat antworten Zitat
Daniel
(Administrator)

Registriert seit: 30. Mai 2002
Ort: Hamburg
15.311 Beiträge
 
Delphi 10.4 Sydney
 
#23

AW: Warum Delphi 64-Bit-IDE

  Alt 7. Mai 2020, 21:08
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?
Daniel R. Wolf
Admin Delphi-PRAXiS
mit Grüßen aus Hamburg
  Mit Zitat antworten Zitat
win568

Registriert seit: 8. Sep 2008
100 Beiträge
 
#24

AW: Warum Delphi 64-Bit-IDE

  Alt 8. Mai 2020, 05:53
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.
  Mit Zitat antworten Zitat
Benutzerbild von Sherlock
Sherlock

Registriert seit: 10. Jan 2006
Ort: Offenbach
3.509 Beiträge
 
Delphi 10.3 Rio
 
#25

AW: Warum Delphi 64-Bit-IDE

  Alt 8. Mai 2020, 06:43
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
Geändert von Sherlock (Morgen um 16:78 Uhr) Grund: Weil ich es kann
  Mit Zitat antworten Zitat
win568

Registriert seit: 8. Sep 2008
100 Beiträge
 
#26

AW: Warum Delphi 64-Bit-IDE

  Alt 8. Mai 2020, 06:54
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. Wir verwenden Jenkins zwar als Unittestserver, aber was soll es uns bei der Entwicklung bringen ??
  Mit Zitat antworten Zitat
Benutzerbild von Moombas
Moombas

Registriert seit: 22. Mär 2017
Ort: bei Flensburg
421 Beiträge
 
FreePascal / Lazarus
 
#27

AW: Warum Delphi 64-Bit-IDE

  Alt 8. Mai 2020, 07:06
Also ich denke wie gesagt, das man sagen kann:
  • Für die meisten Projekte wird durch 64-Bit sich nichts ändern
  • Durch 64-Bit wird es nicht schneller, es steht nur mehr Speicher zur Verfügung (im Prinzip Zukunftssicherer wenn man die steigende Komplexität bei vielen Anwendungen betrachtet)
  • Sollte mit 32-Bit mal das gleiche passieren wie mit 16-Bit (nicht mehr von der CPU unterstützt), wäre man darauf bereits vorbereitet (bei Android z.B. kann man ja soweit ich weiß nur noch 64-Bit hoch laden, da ist der Weg zur "nicht mehr Unterstützung" nicht mehr weit). Man wäre hier also auch Zukunftssicherer.
Der Weg ist das Ziel aber man sollte auf dem Weg niemals das Ziel aus den Augen verlieren.
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
36.133 Beiträge
 
Delphi 10.4 Sydney
 
#28

AW: Warum Delphi 64-Bit-IDE

  Alt 8. Mai 2020, 07:52
Also zugunsten einer Komfortfunktion (Projektgruppe) verzichtet Ihr auf alles andere?
Wir nutzen FinalBuilder und ein CI, was aktuell nur das Testen, aber "noch" nicht das Kompilieren übernimmt,
aber leider haben wir beim Debuggen ein kleines Problem, wodurch der FinalBuilder+Eurekalog die Debugginfos von Delphi schrottet und der Delphi-Debugger somit diese Projekte nicht debuggen kann, außer man kommpiliert im Delphi neu.

Meistens reicht es im Delphi dann nur 1-3 EXE/DLL/BPL zu kompilieren,
aber bis vor Kurzem ist Delphi bei Kompilieren der untersten 25 Packages fast immer komplett abgeraucht. (ja, das war unsere eigene Schuld, aber es hatte ewig bebraucht die Fehler zu finden)
Somit mußte ich öfters, wenn ich "schlimmes" Fehler überall suchen wollte, woher alles löschen, Delphi sauber starten und konnte/musste dann einmal alles durchkompilieren.

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.

Auch wird der "Desktop" nicht gespeichert (XE), wenn man "Speichert", sondern erst wenn man Delphi schließt. Und keine Ahnung wie die das machen, aber wenn Delphi abstürzte, dann wart das auch oft futsch und Delphi startet dann ohne das letzte Projekt zu öffnen mit eimen zerlegten Layout (alles abgedockt und fehlende Module, aber gespeicherter Desktop laden geht zum glück), aber auch nach anschließenden dem Öffnen der Projektgruppe fehlt dann alles, wie geöffnete Dateien und vor allem sind die Haltepunkte weg.


PS: 16 Bit läuft doch noch?
Wenn man DOS, Windows 1 oder ein 32 Bit Windows nutzt. Das 16 Bit-Subsystem wurde doch nur im 64 Bit-Windows entfernt, oder ist es nun auch schon aus 32 Bit raus?
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014

Geändert von himitsu ( 8. Mai 2020 um 07:55 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
7.631 Beiträge
 
Delphi 10.3 Rio
 
#29

AW: Warum Delphi 64-Bit-IDE

  Alt 8. Mai 2020, 08:47
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.

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.

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.

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.
Sebastian Jänicke
Alle eigenen Projekte sind eingestellt, ebenso meine Homepage, Downloadlinks usw. im Forum bleiben aktiv!
  Mit Zitat antworten Zitat
Benutzerbild von Moombas
Moombas

Registriert seit: 22. Mär 2017
Ort: bei Flensburg
421 Beiträge
 
FreePascal / Lazarus
 
#30

AW: Warum Delphi 64-Bit-IDE

  Alt 8. Mai 2020, 09:05
PS: 16 Bit läuft doch noch?
Wenn man DOS, Windows 1 oder ein 32 Bit Windows nutzt. Das 16 Bit-Subsystem wurde doch nur im 64 Bit-Windows entfernt, oder ist es nun auch schon aus 32 Bit raus?
Das hängt von deiner CPU ab (oder dessen benötigter Chipsatz), nicht vom verwendeten Betriebssystem (zumindest ist es mir beim letzteren nicht bekannt).
Bei uns der I3-6100 mit Intel Q270er Chipsatz.
Intel hat bei allen neuen Prozessoren die Unterstützung dessen abgeschaltet.

Bei uns musste ein Softwarelieferant daher viele Routinen nochmal in 32-Bit neu kompilieren, weil das mit der neuen PC-Hardware für die Stores nicht mehr lief (OS ist gleich geblieben; NTVDM hing sich dann immer mit 25% auf).
Wobei er laut Wiki es können soll...

Und die Software ist auch schon uralt...
Der Weg ist das Ziel aber man sollte auf dem Weg niemals das Ziel aus den Augen verlieren.

Geändert von Moombas ( 8. Mai 2020 um 09:29 Uhr)
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 11:25 Uhr.
Powered by vBulletin® Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2020 by Daniel R. Wolf