Delphi beschleunigen

[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.

[jaenicke]

Zitat von 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.

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 von jaenicke:

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.

[bernerbaer]

Zitat von jaenicke:

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.

Rechnerisch und theoretisch stimmt das ja was du sagst, aber mein Alltag sagt halt etwas anderes, innerhalb von 2 Jahren habe ich bei normalem Programmiereinsatz auf einem reinen Arbeitsrechner 3 SSD OCZ verbraten. Ich habe mich deshalb mit Bedauern mal von SSD Festplatten verabschiedet bis die Theorie auch in der Praxis angekommen ist.

[Codehunter]

Zitat von bernerbaer:

innerhalb von 2 Jahren habe ich bei normalem Programmiereinsatz auf einem reinen Arbeitsrechner 3 SSD OCZ verbraten

Jo, hast du schon mal den Gockel zum Thema OCZ SSDs befragt? Die sind bekannt dafür, die schnellsten Datenvernichter auf dem Markt zu sein.

Davon abgesehen, was spricht denn dagegen, eine SSD als Spaßbeschleuniger zu verwenden und diese dann per Sync, Schattenkopie oder sonstwas in Hintergrund auf eine HDD zu spiegeln? Doppelt hält bekanntlich besser. Von einem HDD/SSD-Mix-RAID würde ich aber abraten, da gibt dann auch nur der Langsamste im Bunde den Takt an.