Delphi beschleunigen

[DugDev]

Hallo,

mit welchen Hard- und/oder Software-Maßnahmen läßt sich die Arbeit mit Delphi deutlich beschleunigen?

[musicman56]

Hallo,

am meisten bringt eine SSD :thumb:

[sx2008]

Und natürlich sollte man Projekte nicht auf Netzlaufwerken öffnen sondern immer nur auf lokalen Datenträgern.
Das Problem dabei ist, dass Netzlaufwerke nur unzureichend mit lokalem RAM gecached werden können.

[Bernhard Geyer]

Zitat:

Zitat von sx2008 (Beitrag 1221178)

Und natürlich sollte man Projekte nicht auf Netzlaufwerken öffnen sondern immer nur auf lokalen Datenträgern.

Kann ich nicht bestätigen. Unser D6 "flutscht" bei der Compilierung mit unseren 1 GB-Netzwerkverbindungen ohen viel zu stören

[sx2008]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1221181)

Unser D6 "flutscht" bei der Compilierung mit unseren 1 GB-Netzwerkverbindungen

Das hängt auch vom Betriebssystem ab.
Ab Windows Vista wurde SMB 2 eingeführt, dass besonders bei schnellen Netzwerken die Leistung verbessert. (grössere Datenblöcke, weniger "Ping-Pong" der Datenpakete, Caching von Metadaten)
Also mit Windows XP und 100MBit spürt man einen ganz erheblichen Unterschied zwischen lokalem Datenträger und Netzlaufwerk.

[Der schöne Günther]

Beim Vergleich von PCs mit klassicher Magnetplatte mit SSD-Rechner komme ich immer ganz aus dem Häuschen, das ist wirklich ein gewaltiger Unterschied.

In Sachen RAM komme ich an keine Grenzen, zwischen 4 und 8 GB merke ich keinen Unterschied, zeitweise war ich auch einmal mit 2GB unterwegs und selbst da war alles in Butter.

Ansonsten: Ungenutzte "Experten" aus dem Autostart des RAD Studio nehmen.

[Codehunter]

Projekte sollten eh immer lokal liegen und per Versionsmanagement auf einen Server gespiegelt werden. Ok, als alleinschaffender Kaffeevernichter braucht man das nicht unbedingt, aber für Latenzen beim Compilieren und dem IDE-Start sollten keine der ladbaren Dateien auf einem Netzlaufwerk liegen.

Eine SSD kann ich auch nur wärmstens empfehlen. Allerdings gibt es da auch gute wie schlechte und man muss sein Windows ein bisschen umkonfigurieren (Stichwort Prefetch und Superfetch) damit die Dinger ein bisschen länger halten. Wenn man was stabiles will sollte man am besten zu Intel-SSDs greifen, auch wenn die bissi teurer sind. Die Konkurrenz ist zwar nicht per se schlechter, hat aber eine größere qualitative Streubreite.

Als CPU würde ich eher einen schnellen Dualcore als einen niedriger getakteten Quad oder Hexacore empfehlen. Die Delphi-IDE macht kaum Gebrauch von so vielen Kernen und profitiert eher von hohen Taktraten.

[jbg]

Um den Compiler und die IDE per Software etwas flotter zu bekommen, kann man IDEFixPack installieren.

[stahli]

Zitat:

Zitat von jbg (Beitrag 1221226)

Um den Compiler und die IDE per Software etwas flotter zu bekommen, kann man IDEFixPack installieren.

[OT]Nee, besser nich! Jedesmal wenn das einer macht kriegt Emba einen roten Kopp.[/OT]

[Codehunter]

Zitat:

Zitat von stahli (Beitrag 1221240)

[OT]Nee, besser nich! Jedesmal wenn das einer macht kriegt Emba einen roten Kopp.[/OT]

Solange sie nicht auf irgendeinen roten Knopp drücken... ;-) Wobei ich denen schwerstens empfehlen würde, Andy einzustellen als Qualitätsmanager ^^

Andererseits, ich hab immer irgendwo so ein leichtes Bauchgrummeln wenn ich solche 3rd-party-Konglomerate auf eine Entwicklungsumgebung loslasse. Sowas wird immer erstmal in einer VM getestet.

[musicman56]

Zitat:

Zitat von Codehunter (Beitrag 1221214)

Als CPU würde ich eher einen schnellen Dualcore als einen niedriger getakteten Quad oder Hexacore empfehlen. Die Delphi-IDE macht kaum Gebrauch von so vielen Kernen und profitiert eher von hohen Taktraten.

Das ist absolut richtig. Je nach Arbeitsweise kann sich aber ein Quadcore und ein paar zusätzliche Euro in Hardware investiert schon sehr positiv auf die (Delphi-)Produktivität auswirken. Wenn ich beispielsweise aus der IDE heraus meine App im Debuggmodus starte um damit z.B. externe Daten in die Datenbank einzulesen, was manchmal schon eine halbe Stunde dauern kann, dann kann ich nebenbei andere Dinge prima erledigen. Sogar CD's brennen usw. Das macht absolut keinen Stress mit einem Quadcore 3,3 GHz, Win7-64, 16GB RAM und dem OS auf einer SSD. Hardware kostet ja fast nix mehr. Im Vergleich zu den anderen Produktionskosten (Delphi, Bibliotheken, Arbeitszeit...) fallen die paar Euro überhaupt nicht ins Gewicht. Da spart man meiner Meinung nach manchmal an der falschen Stelle :stupid:

[Nachtrag]
Ich denke, die IDE selber um ein paar Sekunden zu beschleunigen bringt in der Summe nichts oder nur sehr wenig.
[/Nachtrag]

[Codehunter]

Ein schneller Quadcore ist natürlich immer besser als ein schneller Dualcore. Aber vergleicht man innerhalb der selben Preisklasse, dann sind die Dualer eben besser für Delphi geeignet. Es hat auch viel mit den persönlichen Arbeitsgewohnheiten zu tun. Ich brenne eher selten eine CD während nebenher 30 Minuten lang irgendwas im Debugger läuft ;-)

Allgemein hat die CPU bei heutigen Rechnern aber nur noch einen geringen Stellenwert wenn es um die gefühlte Performance geht. Klar ist z.B. das Compilieren sehr CPU-lastig. Aber wie viel Zeit verbringt man denn mit Compilieren und wie viel mit Tippen und IDE-Geklicke?

Für den "Wohlfühlfaktor" bringt eine gute SSD jedenfalls wesentlich mehr als eine Killer-CPU. Sinnvoll konfigurierte Software macht auch einen wesentlichen Teil aus.

[Insider2004]

Mit SSD (Samsunng), WinXP und D7 kompiliere ich jedes Programm unter einer Sekunde.

[musicman56]

@Insider2004

So ähnliche Gedanken gingen mir zuerst durch den Kopf, als ich den Eröffnungsbeitrag las. Mit D7 und XP, übrigens eine Kombination die ich noch in einer VM-Ware laufen habe, stellt sich die Frage eh nur in begrenztem Umfang. 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:

[Satyr]

Apropos VM... ich habe da noch die nervige Eigenart, das es immer mal wieder zu Lags kommt - nur Die Delphi-IDE betreffend. 2-3 Sekunden in denen man sich wundert warum der Code nicht erscheint, den man grade tippt.
Im Grunde nicht schlimm, auf Dauer aber nervig.
Ich vermute da schreibt die VM grade irgendwas auf die Host Festplatte. Zumindest konnte ich das Auftreten mit einer virtuellen Extra-Festplatte auf einer anderen Host-Festplatte die ich nur für die Auslagerungsdatei benutze ein wenig einschränken. Ganz weg ist es aber nicht.
Naja... auch hier wäre wohl eine SSD angebrachter.

[musicman56]

Etwas OT jetzt :?:

Zitat:

Zitat von Satyr (Beitrag 1221284)

Ich vermute da schreibt die VM grade irgendwas auf die Host Festplatte. Zumindest konnte ich das Auftreten mit einer virtuellen Extra-Festplatte auf einer anderen Host-Festplatte die ich nur für die Auslagerungsdatei benutze ein wenig einschränken. Ganz weg ist es aber nicht.
Naja... auch hier wäre wohl eine SSD angebrachter.

Das Phänomen hatte ich noch nicht. Vielleicht hat es ja wie du vermutest etwas mit der SSD zu tun, denn VM-Ware und Windows sind bei mir auf der SSD installiert. Allerdings befinden sich die VM-Ware-Daten (VMware® Workstation, 9.0.2 build-1031769) auf einer normalen HDD.

[jbg]

Zitat:

Zitat von Insider2004 (Beitrag 1221280)

Mit SSD (Samsunng), WinXP und D7 kompiliere ich jedes Programm unter einer Sekunde.

Nicht jedes. Es gibt auch größere. So z.B. die mit denen ich arbeite. Dort dauert das kompilieren trotz SSD bis zu 20 Sekunden mit IDEFixPack und über 2 Minuten ohne ("Generics sei dank" die die CPU zum Kochen bringen). Das Ding besteht aber aus mehreren logischen Teilprojekten (Packages) die beim Kompilieren der EXE-Projekte auch auf geänderte Dateien geprüft werden müssen.

[Insider2004]

Zitat:

Zitat von musicman56 (Beitrag 1221283)

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

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

[musicman56]

Zitat:

Zitat von Insider2004 (Beitrag 1221296)

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:

Zitat von Insider2004 (Beitrag 1221296)

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

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:

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.

[bernerbaer]

Zitat:

Zitat von jaenicke (Beitrag 1221446)

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:

Zitat von bernerbaer (Beitrag 1221477)

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.

[bernerbaer]

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?

[musicman56]

Zitat:

Zitat von bernerbaer (Beitrag 1221477)

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:

Zitat von musicman56 (Beitrag 1221141)

Zitat:

Zitat von Olli73 (Beitrag 1221131)

Zitat:

Zitat von p80286 (Beitrag 1221121)

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 :thumb: 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:

Zitat von Codehunter (Beitrag 1221510)

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:

Zitat von Codehunter (Beitrag 1221510)

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:

Zitat von Codehunter (Beitrag 1221510)

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:

Zitat von Codehunter (Beitrag 1221510)

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

Delphi-Quellcode:

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.