Delphi beschleunigen

[musicman56]

Zitat:

Zitat von jaenicke (Beitrag 1221336)

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:

Zitat von musicman56 (Beitrag 1221283)

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. :cyclops:

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:

Zitat von Codehunter (Beitrag 1221419)

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:

Zitat von Codehunter (Beitrag 1221419)

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.

[jaenicke]

Zitat:

Zitat von OlafSt (Beitrag 1221443)

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.

Mit der Information dürftest du ein paar Jahre hinter der Technik herhinken...

Bei heutigen SSDs kann man rechnerisch die maximalen Schreib- und Lesezyklen kaum erreichen, geschweige denn im normalen Einsatz. Wenn ich das korrekt überschlage müsstest du dafür jeden einzelnen Sektor einer SSD 10 Jahre lang mehrfach pro Stunde neu beschreiben um das zu schaffen.

[Codehunter]

Man kriegt es höchstens noch hin wenn man es ganz bewusst darauf anlegt. Also z.B. indem man eine SSD bis zum Rand befüllt und in die letzten freien 100 kB eine Datei legt mit eben diesen 100 kB und darauf exzessiv rumschreibt.

[Der schöne Günther]

Da musste ich mich neulich auch persönlich belehren lassen, dass dem heute nicht mehr so ist. Anlass war ein Logging-Modul das nichts cached und so oft wie möglich jede Zeile einzeln auf die Platte schreibt. Gut zu wissen :-)

[jaenicke]

Das sollte ein SSD Chipsatz entsprechend durch Umlagerung behandeln.

Wobei es allerdings bei der Haltbarkeit auch auf die verbauten Zellen ankommt. Es gibt da enorme Unterschiede was die Haltbarkeit angeht.

[Codehunter]

Zitat:

Zitat von jaenicke (Beitrag 1221470)

Wobei es allerdings bei der Haltbarkeit auch auf die verbauten Zellen ankommt. Es gibt da enorme Unterschiede was die Haltbarkeit angeht.

Weshalb ich ja in einem früheren Post auf die SSDs von Intel verwiesen habe. Sind vielleicht nicht die allerschnellsten ihrer Art, aber qualitativ immernoch die besten. Und um Längen schneller als eine HDD allemal.