Delphi beschleunigen

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.

Warum wollt ihr denn alle ein schnelleres Delphi?

Ich erinnere mich mit Wehmut an meine Anfangszeiten als Programmierer (ich habe noch Lochkarten gestanzt), da war die Welt noch in Ordnung, der Programmierer noch ein Weltwunder und von allen bestaunt und wenn ich mal Lust auf eine Pause hatte, musste ich nur den Kompiliervorgang starten und konnte dann gemütlich ein bis zwei Stunden in die Kantine gehen.

**Codehunter**

Jo, die Lochkartenjungs waren noch Helden ^^ Ein Stück weit vor meiner Zeit, ich habe mit Basic und Assembler auf dem KC87 angefangen. Wie sah Kompilieren auf einer Lochkartenmaschine eigentlich aus? Ich hab mir das eigentlich immer so vorgestellt, dass man per Lochkarte direkt Maschinencode oder höchstens Assembler eingegeben hat.

**jbg**

Der DCC ist nicht gerade Festplatten lastig (nachdem ein Dateinamen-Cache eingebaut wurde). Er verschlingt Speicher und vor allem CPU. Mit einer SSD wird das Lesen und Schreiben der DCU/EXE/BPL natürlich schneller, aber wenn man im Compiler mal Hashtabellen statt linearen Listen einbauen würde (5sek => 30msec) und der DCC64 nicht so viel Zeit mit "malloc+memset" verbringen würde (17sec => 20msec), könnte er noch so einiges an Geschwindigkeit zulegen. Manchmal frage ich mich schon. Klar, die Codebasis ist alt, aber das da gar nichts in richtig Performance-Optimierung vorangetrieben wird?
Hab ich jetzt schon zu viel vom nächten IDE Fix Pack verraten?

Zitat von bernerbaer:

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

Dieses Problem kannst du ganz einfach vermeiden, indem du

- Betriebssystem und Programme auf der SSD installierst
- Die Benutzerdaten, also auch deine Delphi-Projekte, auf der HDD speicherst.

Meine erste OCZ mit 120 GB ist knapp 3 Jahre alt, davon 2 Jahre in meinem Arbeits-PC und seit etwa einem Jahr in meinem Notebook. Läuft immer noch problemlos.

Aus dem Thread "Benutzerordner komplett verschieben":

Zitat von musicman56:

Zitat von Olli73:

Zitat von p80286:

für mich gibt es eine "Dreiteilung" System(= Programme),unumgänglicher Benutzerschrott (Eigene Dateien) und "echte Daten" die vorzugsweise unter D:\Daten zu finden sind.

Bleibt der "unumgängliche Benutzerschrott" dann auf der SSD, oder kommt der auf die HD?

Der "unumgängliche Benutzerschrott" - aus meiner Sicht also alles was Programme an temporären Dateien anlegen, Broweswercache usw - ist auf der SSD am besten aufgehoben, weil man ja die Ausführungsgeschwindigkeit der Programme nicht ausbremsen möchte.

@p80286 Die Dreiteilung praktiziere ich auch

gehe allerdings noch ein paar Schritte weiter, indem ich Laufwerke/Partitionen verwende:

D: => Alles was mit Delphi zu tun hat
E: => Alle fertigen (Delphi-)Programme
F: => Firmendaten und ein Teil der Userdaten
G: => frei für Wechseldatenträger
H: => CD-Laufwerk
M: => Alles was mit Musik/Multimedia zu tun hat
P: => Alle privaten Daten

So wird mit Acronis fast täglich C: und D: gesichert, F: mindestens 1x in der Woche und M: und P: nur ab und zu, weil's insgesamt ca. 1,3 TB Daten sind. Auch die Zugriffsgeschwindigkeit ist damit etwas verbessert, weil die höheren Laufwerksbuchstaben/Partitionen wenig fragmentiert werden, und physikalisch auf der Innenseite der HDD liegen, und die Delphi-Daten die sich täglich ändern auf der Außenseite, wo die Zugriffszeit am schnellsten ist.

**Codehunter**

Ja die Diskussion geht jetzt ein bisschen in die falsche Richtung. Denn das was Delphi gefühlt so langsam macht sind eigentlich andere Dinge. Der Start der IDE wäre ein Punkt. Die Latenzzeiten bei der Quellcodevervollständigung wäre ein anderer. Die Zeit bis die Hilfe startet ein dritter. Das alles ist ziemlich Datentreter-lastig, egal ob nun HDD oder SSD, auch wenn letztere schneller treten

Dem Compiler helfen am besten ein oder zwei schnelle CPU-Kerne und flotter RAM auf die Sprünge, der Rest lässt sich eher per SSD ankurbeln. Worauf man mehr Wert legt muss jeder für sich entscheiden.

**jaenicke**

Zitat von Codehunter:

Der Start der IDE wäre ein Punkt.

Die finde ich nicht schlecht. Das sind 3-4 Sekunden bei mir, ohne Zusatzaddons usw. ca. 2 Sekunden mit XE4 und einem mittlerweile nicht mehr taufrischen PC (Phenom II x4 955), aber natürlich mit Windows 8 und SSD.

Zitat von Codehunter:

Die Latenzzeiten bei der Quellcodevervollständigung wäre ein anderer.

Ja, das sind schon mal 1-2 Sekunden bei größeren Projekten...
Zum Glück passiert das eher selten, meistens ist es ja schnell...

Zitat von Codehunter:

Die Zeit bis die Hilfe startet ein dritter.

Die habe ich nicht einmal mehr installiert bei XE4, da ich sie ohnehin nie brauche und daher nie nutze.

Zitat von Codehunter:

Dem Compiler helfen am besten ein oder zwei schnelle CPU-Kerne und flotter RAM auf die Sprünge, der Rest lässt sich eher per SSD ankurbeln. Worauf man mehr Wert legt muss jeder für sich entscheiden.

Ja, vor allem die CPU Leistung hilft auch gut. Bei mir ist die CPU im Moment der limitierende Faktor, die SSD könnte schneller.

**Codehunter**

Bei mir ist im Moment die Polizei der limitierende Faktor, das Auto könnte schneller ^^

Ich würde sagen, wir haben jetzt so ziemlich alles erörtert was man tun kann zum IDE beschleunigen. Oder hab ich was übersehen?

**Der schöne Günther**

"IDE Startup Time" war sogar in der letzten Emba-Umfrage ein Punkt, wie zufrieden man denn damit ist. Ich finde die gradezu fantastisch. Insbesondere an der Menge an Drittanbieter-Kram, der noch mitgeladen wird.

Die ganzen IDE-Fehler ("Error Inside", Code Insight, ...) - Die sind bei mir der am meisten limitierende Faktor. In Sachen IDE könnte sehr, sehr viel mehr Hilfe kommen. Warum muss ich mir ständig raussuchen, welche Standard-Units ich einbinden muss? Entweder habe ich etwas verpasst (nicht unwahrscheinlich), oder es ist ein Unding, dass ich jedesmal, wenn ich zum ersten mal eine Liste verwende, zum interface oder implementation-Teil scrollen muss und uses ... System.Generics.Collections, ... ; eintippen muss. So etwas sollte man mal beschleunigen.

Die IDE Startup-Zeit ist meiner Meinung nach großartig, die Compiler-Geschwindigkeit mindestens gut.