Warum Delphi 64-Bit-IDE

[freimatz]

... die gibt es nicht.

Nur interessehalber: Warum sollte man die haben wollen?

Dass früher mal Fehlermeldungen wegen zu wenig Speicher kamen, lag ja wohl an Memory-Leaks und nicht dass die IDE nur 3GB RAM bekommt.

Oder liegt es dass man zum Debuggen von 64-Bit, den Remote Debugger nehmen muss?
Oder hofft man dass dann die Problem beim debuggen von 64-Bit weg sind?

[hoika]

Hall,
1. RAM-Verbrauch bei großen Projekte
2. RemoteDebugger
3. andere IDEs können das auch (...)

[arnof]

ich sehe mehrmals täglich: "zu wenig Arbeitsspeicher" oder "out of memory"

Dies tritt auf, wenn die bds.exe über 1.2 GByte RAM zugewiesen bekommt. Mein Entwicklungssystem hat 64 GB und genug freien Speicher im Block ...

Meine Lösungen bisher:

- möglichst wenige Fenster in der IDE zur Bearbeitung auf haben
- Release erzeugen und Debugmodus in nur den Sachen die mich gerade interessieren

Regelmäßig neu starten ......

Aber ich benutze aktuell zum Arbeiten XE2 mit vielen Komponenten Devexpress, TMS usw.

Mit RIO und den Vorgängern mach ich nur "Spass" Prgs wie Apps, WEB und REST

[Stevie]

Zitat von hoika:

andere IDEs können das auch (...)

Fun fact: Visual Studio ist auch in der 2019er Version nicht 64bit, besteht aber aus einer Vielzahl von Prozessen, die miteinander kommunizieren.

Auch interessant: https://stackoverflow.com/a/46510321/587106

[Bernhard Geyer]

Zitat von arnof:

Aber ich benutze aktuell zum Arbeiten XE2 mit vielen Komponenten Devexpress, TMS usw.

Mit aktuellen 10.xer Versionen würdest du dir vermutlich fast alle Restarts sparen.
Da hat sich schon gewaltig viel getan.

[jaenicke]

Zitat von arnof:

Aber ich benutze aktuell zum Arbeiten XE2 mit vielen Komponenten Devexpress, TMS usw.

Ja, da war das noch ein größeres Problem. Bis XE6 oder XE7 ging das glaube ich so.
Mit XE8 und 10 wurde das aber größtenteils behoben. Und die IDE kann nun auch 3 statt 2 GB RAM ansprechen.

Jetzt kann man auch weitestgehend problemlos in größeren Projektgruppen gleichzeitig Haltepunkte in DLL und Hostprogramm nutzen und zwischen den Projekten umschalten usw. ohne dass es gleich Abstürze gibt.

In den aktuellen Versionen gibt es daher vom Speicherverbrauch her nicht mehr die große Notwendigkeit einer 64-Bit IDE. Und man sollte bedenken, dass man dann die ganzen Komponentenpackages auch in 64-Bit Versionen bereitstellen und haben muss.

[arnof]

Nach dem TSE Kram, hatte ich vor auf RIO zu wechseln; jetzt kommt aber 10.4, dann warte ich halt wieder bis alle Komponentenhersteller liefern können, dann ist wieder Herbst und man hat keine Zeit zu wechseln. Dann kommt 10.5, so geht das Jahr für Jahr bzw halbjährlich ....

Der Wechsel von Delphi 5 auf XE2 hat sicherlich, bis man das was rauskommt an Kunden liefern kann 2-3 Monate gedauert, die Zeit hat man halt nicht immer ...

[DieDolly]

Zitat:

dann ist wieder Herbst und man hat keine Zeit zu wechseln. Dann kommt 10.5

Lass es Sommer 2021 sein, bis 10.5 kommt. Vorher bestimmt nicht. Du hast also genug Zeit.

Ich muss die IDE zwar mehrmals täglich wegen irgendwelcher unbehandelten Fehler, von denen es viele gibt, neustarten. Aber an Speicherlimits bin ich bisher nie gekommen.

[Bernhard Geyer]

Zitat von arnof:

Nach dem TSE Kram, hatte ich vor auf RIO zu wechseln; jetzt kommt aber 10.4, dann warte ich halt wieder bis alle Komponentenhersteller liefern können, dann ist wieder Herbst und man hat keine Zeit zu wechseln. Dann kommt 10.5, so geht das Jahr für Jahr bzw halbjährlich ....

Also ich habe meine Komponentensammlung selbständig innerhalb weniger Stunden "auf Vordermann" gebracht.
Ist bei vielen nur 1-2 inc-Datei die man nach "Schema F" ergänzen muss.
Die Quellcodeanpassungen (wegen Verschobener Klassen) sind auch in den letzen XEx und 10.xer Versionen auch sehr übersichtlich geworden.

Zitat von arnof:

Der Wechsel von Delphi 5 auf XE2 hat sicherlich, bis man das was rauskommt an Kunden liefern kann 2-3 Monate gedauert,

Yo. Der Wechsel von Nicht-Unicode auf Unicode-Version hat bei uns auch gedauert (D6->XE6)
Der folgende Wechsel von XE6 auf 10.2 war erheblich schneller "durch".
Und die Produktivität ist auch mit XE6 -> 10.2 wieder merklich gestiegen (wenn man mal "Spaß" an den neuen Sprachfeatures findet ...)
Stabilität auch (bei uns) merklich besser.

Zitat von arnof:

die Zeit hat man halt nicht immer ...

Man hat auch noch viel weniger Zeit die Einschränkungen von alten Compilern "zu umschiffen".

[himitsu]

1,2 GB sagt nichts aus.
* Es kommt drauf an wieviel Speicher reserviert werden sollte (auch bei nur 10 MB RAM wird gemeckert, wenn jemand 2 GB reservieren will)
* und wie fragmentiert der Speicher schon ist
** meiner Erfahrung nach, gibt es schon ab GetMem(700 MB) Probleme, dass es oft in einem ganz kleinen Programm keinen freien "zusammenhängenden" Bereich mit dieser Größe mehr gibt

Die Delphi-IDE wurde vor "kurzem" zumindestens schonmal mit der 4GB-Option ausgestattet.
* in 32 Bit-Windows bis 3 GB (weil das OS für Kernel und Treiber bissl was braucht) und in 64 Bit-Windows bis 4 GB (nja, 3.9xx) virtueller Speicher

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.
Da man nun aber etwas mehr Speicher hat, knallt es nicht mehr so schnell (wenn wir es bald hoffentlich geschafft haben von XE auf 10.x upzugraden, denn jetzt hab ich den Bug noch)



Problem ist halt, dass dann auch alle DesignTime-Komponenten (die sollten das meistens schon können) und vor allem auch die DesignTime-Editoren dieser Komponenten und sämtliche andere IDE-Experten/Plugins ebenfalls in 64 Bit vorliegen müssen,
denn sonst hast zwar eine schöne IDE, aber die dann ein bissl leer.


Von mir aus kann man die 32 Bit-IDE dann auch einstampfen, um nicht doppelt weiterentwickeln zu müssen, dann effektiv gibt es keine kaum noch Entwicklungsrechner mit einem 32 Bit-Windows, wo ein nagelneues Delphi drauf muß.