Delphi beschleunigen

[Insider2004]

Zitat von musicman56:

@Insider2004

Speicherkonsum von D7 bei einem durchschnittlichen Projekt zwischen 50 und 80 MB. Wenn ich mit XE2 einen Build meiner Projektgruppe laufen lasse, kackt die IDE bei etwa 1.2 GB Arbeitsspeicherverbrauch ab.

In XE2 sind es auch nur 80MB. Die restlichen 1120MB sind wertlose Speicherleaks.

[musicman56]

Zitat von Insider2004:

In XE2 sind es auch nur 80MB....

Aber nur bei einem leeren "Hello World"-Projekt mit einer einzelnen Form. Aber darum ging es mir gar nicht. Ich wollte lediglich den mittlerweile sehr großen Unterschied im Ressourcenverbrauch zwischen D7 und den aktuellen Versionen verdeutlichen. Woraus folgt: das Optimierungspotential bei D7 ist nicht allzu groß. Die SSD bringt am meisten.

Sorry, das hätte ich bereits bei der ersten Antwort etwas anders und deutlicher formulieren können.

[jaenicke]

Zitat von Insider2004:

In XE2 sind es auch nur 80MB. Die restlichen 1120MB sind wertlose Speicherleaks.

Von Speicherlecks merke ich aktuell in XE4 nicht mehr viel. Es mag welche geben, aber in der Regel läuft XE4 von morgens bis abends ohne es neuzustarten durch und der Arbeitsspeicherverbrauch ist am Ende nicht signifikant höher als am Anfang.

Beim Remotedebuggen hakelt es noch etwas, da scheint es auch Speicherlecks zu geben, aber das benutze ich im Moment weniger, so dass ich dazu nicht viel sagen kann.

Beim Kompilieren geht der Arbeitsspeicherverbrauch ziemlich nach oben, wird aber nicht bei jedem Kompilieren mehr, so dass hinsichtlich Lecks dort zumindest mit unseren Projekten alles in Ordnung zu sein scheint. Dass allerdings ein mittelgroßes Projekt schon zu 700 MiB Arbeitsspeicherverbrauch führt, finde ich schon etwas viel. (Das Projekt hat gerade mal etwas mehr als eine halbe Million Zeilen.)

[musicman56]

Zitat von jaenicke:

Beim Kompilieren geht der Arbeitsspeicherverbrauch ziemlich nach oben, wird aber nicht bei jedem Kompilieren mehr, so dass hinsichtlich Lecks dort zumindest mit unseren Projekten alles in Ordnung zu sein scheint....

Stimmt, da ist die Delphi-Welt noch in Ordnung. Das Stichwort in diesem Kontext ist "Projektgruppe"....

Zitat von musicman56:

Speicherkonsum von D7 bei einem durchschnittlichen Projekt zwischen 50 und 80 MB. Wenn ich mit XE2 einen Build meiner Projektgruppe laufen lasse, kackt die IDE bei etwa 1.2 GB Arbeitsspeicherverbrauch ab.

Ich möchte jetzt keinen alten Kram wiederbeleben, die zugrundeliegende Problematik wurde hier schon ausreichend besprochen. Sorry, ich finde leider den Thread nicht mehr.

[Codehunter]

Wie ist das denn eigentlich beim Erzeugen eines Projektes, legen Compiler und IDE da auch temporäre Dateien an oder verlässt man sich da komplett auf RAM und Auslagerungsdatei? Ich hab das noch nicht so genau verfolgt. Aber falls temporäre Dateien ins Spiel kommen, würde eine SSD zusätzlich noch beim Compilieren Vorteile bringen, nicht nur beim IDE-Start.

Unter Linux gibt es ja ständig Bestrebungen, die Compiler zu optimieren und an die neuesten CPU-Generationen anzupassen. Da werden auch die erweiterten CPU-Befehlssätze mit rangezogen, teilweise sogar Techniken wie CUDA (hab ich mal irgendwo gelesen). Bei Emba scheint man in der Richtung nicht viel Enthusiasmus zu haben, denn dcc32 von XE2 läuft für sich allein sogar noch auf einem Pentium-1-Rechner, nur die IDE halt nicht. Was aber vermutlich weniger an der IDE liegt sondern an der simplen Tatsache dass man P1-Rechner nur schwerlich auf 4 GB RAM aufrüsten kann und Win XP auch nicht so recht darauf laufen mag.

[jaenicke]

Zitat von Codehunter:

Aber falls temporäre Dateien ins Spiel kommen, würde eine SSD zusätzlich noch beim Compilieren Vorteile bringen, nicht nur beim IDE-Start.

Naja, temporär kann man die nicht wirklich nennen, aber jede Unit wird ja aus dem Quelltext gelesen, kompiliert und in einer .dcu abgelegt. Deshalb gibt es da genug Dateioperationen, die eine SSD beim Kompilieren deutlich spürbar machen.

Zitat von Codehunter:

Unter Linux gibt es ja ständig Bestrebungen, die Compiler zu optimieren und an die neuesten CPU-Generationen anzupassen. Da werden auch die erweiterten CPU-Befehlssätze mit rangezogen, teilweise sogar Techniken wie CUDA

Das liegt aber auch daran, dass C++ was Compilezeit angeht nicht sonderlich effizient ist. Delphi ist durch seinen Single-Pass-Compiler schon von sich aus sehr schnell. C++ denkt eben teilweise deutlich länger nach.

Single-Pass hat bei Delphi allerdings den Nachteil, dass Features wie LINQ nur schwer umzusetzen sind.

[Codehunter]

Von den DCUs mal abgesehen, das ist klar ^^ Wobei die ja auch nicht unbedingt bei jedem Compilerlauf neu angelegt werden. Es sei denn man hat an der entsprechenden PAS was geändert oder hat gesagt, dass alles kompiliert werden soll.

Ich meinte richtige temporäre Dateien, die im TMP-Ordner angelegt werden. Wenn ich da an MS Word, Corel Draw und Konsorten denke, die produzieren ja haufenweise von dem Zeug. Das sind hochvolatile Dateibestände, da kommt man sich beim Wechsel von HDD gegen SSD vor als hätte man einem Trabimotor gleichzeitig einen Turbolader und Nitroanlage spendiert

Ich selbst habe zwar keinen Rechner, wo Delphi auf einer SSD läuft. Aber ich habe vor einigen Monaten mal einen Laptop mit einem Core2 Duo von HDD auf SSD und von 2 GB auf 8 GB RAM umgerüstet. An der Arbeit im Büro habe ich dagegen einen AMD Phenom X6 1090T mit HDD und 8 GB RAM stehen. Da fiel mir plötzlich die Kinnlade auf die Tischplatte als ich den Unterschied gesehen habe. Bei allem, was nicht gerade sehr CPU-lastig ist, steckt der 6 Jahre alte Lappi den großen Rechner locker in die Tasche.

[OlafSt]

Man sollte aber auch nicht vergessen, das massenhafte Schreibzugriffe eine SSD in kürzester Zeit töten. Da helfen auch SSD-interne "Wear-Load"-Algorithmen irgendwann nicht mehr.