DelphiSpeedUp 2.8 ( 2009-12-01 ) - Delphi 5 bis 2007

[alzaimar]

Wenn Du diesen Thread durchgelesen hättest, dann wüsstest Du, das DSU nichts damit zu tun hat. DSU ist wie ein Haufen kleiner Bauteile, die einen Benzinmotor von der Stange einfach wesentlich schneller laufen lassen. Dumm nur, wenn man Diesel tankt. Oder wenn ein wenig Kaffee in die Leitung tröpfelt. Dann knallen eben auch diese Bauteile. Da sie intern anders funktionieren, als die ausgetauschten, kommt es dann eben zu solchen Effekten.

D2005 ist meines Wissens nach auch nicht gerade berühmt für Stabilität.

[oki]

Zitat:

Zitat von alzaimar

Wenn Du diesen Thread durchgelesen hättest, dann wüsstest Du, das DSU nichts damit zu tun hat. DSU ist wie ein Haufen kleiner Bauteile, die einen Benzinmotor von der Stange einfach wesentlich schneller laufen lassen. Dumm nur, wenn man Diesel tankt. Oder wenn ein wenig Kaffee in die Leitung tröpfelt. Dann knallen eben auch diese Bauteile. Da sie intern anders funktionieren, als die ausgetauschten, kommt es dann eben zu solchen Effekten.

D2005 ist meines Wissens nach auch nicht gerade berühmt für Stabilität.

Hi alzaimar,

ich glaube, den Thread komplett durchzulesen ist wohl kaum noch möglich :lol: . Aber im Ernst, ich kann bestätigen, dass Probleme mit Delphi bei mir eigentlich nie was mit DSU zu tun hatte. Ich habe DSU mit D7 und D2007 im Einsatz. Absturzprobleme oder eine immer langsamer werdende IDE konnten immer mit anderen Maßnahmen beseitigt werden. Ein Problem waren Fehler in Delphi die durch Updates und andere Maßnahmen gefixt werden konnten und unter D2007 habe ich festgestellt, das ausreichend RAM (min. 2GB) ein absolutes Muß sind um Delphi stabil am Laufen zu halten. Nachdem somit Delphi sauber lief hat DSU genau das gemacht was es soll, nämlich Delphi beschleunigt. Nachweisbare Fehler hat es bei mir jedenfalls nicht verursacht. Alles konnten im Rahmen der Möglichkeiten durch andere Maßnahmen beseitigt werden (mit dem Rest muss man leben, da ändert die Deinstallation von DSU auch nichts dran).

Ich jedenfalls benutze DSU schon lange und es bringt genau das was beschrieben steht, den Start von Delphi wesentlich beschleunigen.

Gruß oki

[jaenicke]

Zitat:

Zitat von oki

und unter D2007 habe ich festgestellt, das ausreichend RAM (min. 2GB) ein absolutes Muß sind um Delphi stabil am Laufen zu halten.

Also mit Vista 32-Bit, Delphi 2007 und 1GiB RAM gab es bei mir keinerlei Probleme, es lief auch schnell, auch im virtuellen PC mit XP und 192 MiB RAM läuft es gut (da hatte ich allerdings nie größere Projekte offen).

Zitat:

Zitat von Fuchtel

auch ich habe mit Delphi 2005 ähnliche Absturz Probleme:

Dass Delphi 2005 verbuggt ist, ist klar. Insbesondere haben mich die Speicherlecks genervt und dass das Umschalten zwischen Formular und Unit oder zwischen Units so langsam war.
Gibt es einen Grund dafür, dass du das statt Turbo Delphi verwendest? :gruebel:

[Fuchtel]

Zitat:

Gibt es einen Grund dafür, dass du das statt Turbo Delphi verwendest?

Ja, wird vom Auftraggeber so gefordert!

Fuchtel

[mkinzler]

Zitat:

Zitat von Fuchtel

Zitat:

Gibt es einen Grund dafür, dass du das statt Turbo Delphi verwendest?

Ja, wird vom Auftraggeber so gefordert!

Fuchtel

Anforderungen gibts. :gruebel:
Da in D2005 der gleiche Compiler wie in D7Upd2 werkelt, würde ich hier sogar D7 den Vortritt geben

[alzaimar]

Zitat:

Zitat von oki

ich glaube, den Thread komplett durchzulesen ist wohl kaum noch möglich :lol: .

Post #753 und die paar davor auf *dieser* Seite reichen eigentlich. :zwinker:

[gsh]

Hallo irgendwie hab ich das Gefühl das viele meinen Beitrag #759 überlesen haben.

Ich hab Delphi 2006, XP SP3 und totale Stabilitätsprobleme. Ich will aber nicht komplett DSU die schuld gegeben aber ein nicht wiederlegbares Faktum ist das mein Delphi seitdem ich DSU deinstalliert hab absolut stabil läuft. Was ich beim ersten Mal vergessen hab zu erwähnen ist mit DSU auch während dem Programmieren ohne reporduzierbares verhalten immer wieder einmal Zeigerfehler aufgetreten sind. Manachmal hat man diese nicht mehr wegklicken können weil sie sofort wieder gekommen sind.

Ich wäre echt total froh um eine Lösung wie ich mein Delphi mit DSU stabil machen kann. :dp:

[oki]

Zitat:

Zitat von jaenicke

Also mit Vista 32-Bit, Delphi 2007 und 1GiB RAM gab es bei mir keinerlei Probleme, es lief auch schnell, auch im virtuellen PC mit XP und 192 MiB RAM läuft es gut (da hatte ich allerdings nie größere Projekte offen).

ich hatte diese Probleme vorwiegend mit recht großen Projekten. Das gestaltete sich so, dass Delphi ca. nach einer Stunde Arbeit immer mehr Speicher belegte. Vorwiegend wenn viele Builds durchgeführt wurden. Meine Speicherauslastung lag nach ca. 3 Stunden intensiver Arbeit bei ca. 1,2 GB. Zuerst stieg immer die Fehlermarkierung aus (alles mögliche war rot unterstrichen) und dann wurde Delphi unendlich lahm. Zeiten für ein Build stiegen von 10 Sehunden auf ca. 1 Minute. Mit Autospeichern war fast gar kein Arbeiten mehr möglich. Zu diese Zeit hatte ich auch alles mögliche versucht, incl. Deinstallation DSU. Kurzfristige Abhilfe hat nur das Beenden und neu Starten von Delphi gebracht. Erst nach dem ich den Rechner "fitt" gemacht hatte waren die Probleme werg (incl. diverser Patches; nicht nur von Code Gear).

Gruß oki

[Regan]

Zitat:

Zitat von gsh

Ich hab Delphi 2006, XP SP3 und totale Stabilitätsprobleme.

Also ich habe die Turbo-Linie (ist ja von Delphi 2006 abgeleitet) und habe mit der Kombination eigentlich keine Probleme.

[jbg]

Tot geglaubte leben länger. :mrgreen:
Seit über einem Jahr gab es kein Update mehr für DelphiSpeedUp. Nun ist es aber wieder so weit.

Bei Projekten, die sehr viele Units oder Packages benutzen, kann das "Step Into" in eine Unit, die ohne Debug-Infos kompiliert ist, und das Pausieren der Anwendung mehrere Minuten dauern. Klar in der Zeit kann man sich einen Kaffee holen, aber so viele Tassen will ich gar nicht am Tag trinken.
Da dieses Problem mit Delphi 2009/2010 bereits seitens Embarcadero behoben wurde, habe ich mich hingesetzt und dieses auch für Delphi 6 bis 2007 gemacht. (Delphi 5 scheint den dafür zuständigen Code gar nicht zu enthalten oder der Maschinencode sieht gänzlich anders aus).


DelphiSpeedUp 2.8 kann wie üblich von der ersten Seite des Threads heruntergeladen werden.

[Matze]

Thementitel:

DelphiSpeedUp 2.8 ( 2009-11-30 ) - Delphi 5 bis 2007

Kommt das erst morgen raus? :stupid:

[DeddyH]

Erbsenzähler :stupid:. Auf jeden Fall noch einmal herzlichen Dank an Andreas für dieses tolle Tool.

[toms]

Zitat:

Zitat von Matze

Thementitel:

DelphiSpeedUp 2.8 ( 2009-11-30 ) - Delphi 5 bis 2007

Kommt das erst morgen raus? :stupid:

Nein, heute. (DelphiSpeedUp 2.8 testers needed (D6-D2007)...)

[mirage228]

Zitat:

Zitat von toms

Nein, heute. (DelphiSpeedUp 2.8 testers needed (D6-D2007)...)

Delphi 2005 Update 3 + inoffizielle Updates, Windows 7 Professional 32bit Deutsch:
Scheint nach einem Kurztest zu funktionieren, jedoch enthält das Compiler-Meldungsfenster nach Beenden der Applikation mehrfach die Zeile:

Zitat:

[Fataler Fehler] F2084 Interner Fehler: BC189

(BC steht für den Debugger). Diese Zeile kommt so ca. 1900 mal...

Viele Grüße

[RWarnecke]

Auch von mir nochmal ein herzlichstes Dankeschön. Habe gerade das Update durchgeführt. :thumb:

[jbg]

Zitat:

Zitat von mirage228

Scheint nach einem Kurztest zu funktionieren, jedoch enthält das Compiler-Meldungsfenster nach Beenden der Applikation mehrfach die Zeile:
[Fataler Fehler] F2084 Interner Fehler: BC189

Für Delphi 2005 hatte ich ein $IFDEF falsch gesetzt, so dass die Offsets nicht mehr gepasst haben. Was mich ein wenig verwundert ist, dass in Delphi 7 das Feld an Offset $0E steht, in Delphi 2006+ an Offset $14 und bei Delphi 2005 der Offset $18 steht. Da scheint wohl mal was in Delphi 2005 eingebaut worden zu sein, dass in Delphi 2006 wieder entfernt wurde.

Ich habe eine neue "All in one" Zip-Datei hochgeladen. (Nur die Delphi 2005 DLL wurde geändert, sonst wurde nichts neu kompiliert).

[taaktaak]

mal 'ne bescheidene Frage:
Wieso gibt's noch keine Ausgaben für D2009 / D2010? Bei D2010 dauert der Start ja um ein Vielfaches länger als bei D7... Funktioniert die Beschleunigung prinzipiell nicht mehr oder ist das "in Arbeit"?

[himitsu]

@tatkttak: runterscrollen
http://andy.jgknet.de/blog/

[taaktaak]

Hmmm, hmm und noch mal hm:

Habe jetzt zwar (sehr interessant!) etwas zum missratenen F1 im Objektinspektor gelesen, aber eine Antwort auf meine Frage auch beim "runterscrollen" nicht entdecken können.

himitsu, wo versteckt sich die Antwort?
:roll:

[himitsu]

"IDE Fix Pack 2.71 for RAD Studio 2009 (only)" klang irgendwie passend
und ich dachte ich hätte noch was für 2010 gesehn :gruebel:

Ansonsten sind viele Dinge vom FastCodeProjekt und FastMM schon integriert.

[DeddyH]

Zitat:

Where is DelphiSpeedUp for Delphi/C++Builder 2009
There is no need for a DelphiSpeedUp for Delphi/C++Builder 2009 yet. The IDE is faster than Delphi 2007 with an installed DelphiSpeedUp. All other features are now part of DDevExtensions.

[taaktaak]

Jooo, ein FixPack für D2010 ist da auch zu finden. Das dieses "FixPack" aber dem "Speedup" entspricht ist für mich nicht so ganz nachvollziehbar. Schließlich gibt es für D2007 ein Speedup und ein FixPack, seltsam...

edit:

ah, wo kommt denn der letzte Post von Detlef plötzlich her?

Tja, also "there is no need..." ist ja 'ne echt deprimierende Aussage. Habe zwar die Zeit noich nicht gestoppt, aber wie ich schon geschrieben habe: ..dauert um ein Vielfaches länger als der Start von D7" - Na, ist wohl so. Wenn man den PC nicht mehr ausschaltet und Delphi ständig geladen hat, dann ist das alles auch kein Thema mehr. Die Energieversorger freuen sich :mrgreen:

[jbg]

Zitat:

Zitat von taaktaak

Tja, also "there is no need..." ist ja 'ne echt deprimierende Aussage.

Das Problem ist, dass alles was DelphiSpeedUp zu bieten hat bereits von Embarcadero in Delphi 2009 aufgenommen wurde. (Die haben den Quellcode von mir bekommen). Und was nicht aufgenommen wurde ist im DDevExtensions Plugin oder dem IDE Fix Pack gelandet.

Das Delphi 2009 so lange braucht liegt daran, dass es im Vergleich zu Delphi 7 einiges mehr laden muss. Darunter fällt auch das schwergewichtige .NET Framework und der Rotz der Together-Integration, die für das Refactoring notwendig ist und in J# geschrieben wurde (bin mal gespannt wann die das nach C# migrieren, weil J# von Microsoft nicht mehr weiterentwickelt wird. Hätten die es gleich von Java nach C# umgeschrieben, müssten sie nicht erneut ran).

Wenn man sich die Startzeit von Delphi 2005-2007 im Vergleich zu Delphi 2009 und vor allem 2010 anschaut, dann merkt man schon, dass da einiges an Geschwindigkeit zugelegt wurde.
Mein Delphi 2010 braucht 12 Sekunden um kalt zu starten und warm braucht es 6 Sekunden. Da lässt sich nicht mehr viel optimieren.

[taaktaak]

Vielen Dank für die Erläuterungen.
:hi:

Habe mein subjektives Empfinden nun durch einige Zeitmessungen ersetzt: Der "Kaltstart" dauert etwa 40 Sekunden bis zur Betriebsbereitschaft; bis das "schwarze Fenster" als erstes "Lebenszeichen" erscheint, braucht es immerhin etwa 10..12 Sekunden.

Das ist natürlich ein deutlicher Unterschied zu deinen Werten! Bislang war ich mit meinem System (Athlon 64 X2 4600+, 2 GB RAM und Win XP) eigentlich recht zufrieden, auch die Festplatten sind nicht unbedingt soooo alt. Aber irgendworan muss der heftige Unterschied ja liegen :shock:

[jbg]

Zitat:

Zitat von taaktaak

Athlon 64 X2 4600+, 2 GB RAM und Win XP

Mir ist aufgefallen, dass Delphi unter Vista (und Win7) spürbar schneller startet. Ist aber vielleich auch nur subjektiv.

Ich habe mir aber gerade die mühe gemacht und nachgeschaut, ob Delphi immernoch beim Starten den C# Compiler anwirft. Und tatsächlich macht es dass. DelphiSpeedUp führt den C# Compiler nur einmalig aus nutzt dann das "gecachete" Assembly bei jedem weiteren Start. Diese Optimierung könnte ich also wieder reaktivieren.

[jbg]

So und nun ist der erste Release Candidate für DelphiSpeedUp 2.8 verfügbar. (Zu erkennen an der Datei Version.txt die nun "2.8" enthält statt dem "2.78").

Änderungen (Alles wieder entfernt und neu geschrieben)

• Der Speichermanager des Compilers wird nun nicht mehr umgebogen, da FastMM einfach mehr RAM beansprucht und es somit zu "Out of Memory" Exceptions kommen konnte, wenn genügend Projekt geöffnet waren
• Der Step-Into Patch nutzt nun eine neue Strategie, gegen die der alte Patch sich wie eine lahme Ente anfühlt. Wem es was sagt: Ich habe für 95% der Falle ein O(1) erreicht, die restlichen 5% nutzen den Original-Code.
• Delphi 5 ist von der Optimierung nun ausgenommen, da es dort nur Probleme gab

Downloads auf der ersten Seite des Threads sind aktualisiert.

[win568]

Hi Andreas

Kannst du den Patch auch für D2010 zur Verfügung stellen. Wir haben das Problem mit dem Step Into dort leider auch. Liegt zwar bereits seit Monaten auf QualityCentral, aber Embarcadero reagiert leider genauso wie Inprise oder Borland auf solche Eingaben.

[jbg]

Zitat:

Zitat von win568

Kannst du den Patch auch für D2010 zur Verfügung stellen.

Können schon, nur bringt er da nicht viel.

Zitat:

Wir haben das Problem mit dem Step Into dort leider auch. Liegt zwar bereits seit Monaten auf QualityCentral

Dabei handelt es sich höchstwahrscheinlich nicht um das Step-Into Problem, sondern darum, dass der Aufrufstack und die "Lokale Variablen"-Ansicht die Zeit verschlingen. Inbesondere letzere braucht ziemlich viel Zeit und hätte meiner Meinung nach asynchron gelöst werden müssen. Aber das Wort "asynchron" ist für die ein Fremdwort, denn was bringen zig Threads, wenn jeder davon den Compiler mit einem Mutex locked und somit die Threads serialisiert ausgeführt werden.

[win568]

Hi Andi

Auch das haben wir bereits ausgetestet. Es hat leider nur geringe Verbesserungen gebracht. Auch wenn alle Fenster geschlossen sind (ich hoffe dann wird die Funktion auch nicht ausgeführt), benötigt Delphi bei F7/F8 zwischen 3-4 sec pro Schritt. Da bei uns ~100 Entwickler mit Delphi arbeiten, ist das derzeit für uns ein absolutes Killerkriterium. Mir kommt es so vor, dass Delphi mit jeder Version schlechter wird. Mit D2006 haben wir keinerlei Probleme mit unseren 9 Mio Locs. Mit D2007 ist es schon etwas schlechter geworden (~ 2-3 sec) mit D2009 nochmals schlechter (~ 3 sec) und mit D2010 (~3-4 sec) pro Schritt. Auch wenn die immer mehr Funktionen reinpacken, darf das nicht das Resultat sein. Wir haben es sowohl auf Vista 32/64 als auch Win7 32/64 getestet.

[jbg]

Wie ist denn die QualityCentral Report-Nummer. Ich kann mal versuchen meine Kontakte spielen zu lassen.

[win568]

Cool. Dank da recht. Die Nummer ist 75738.

[jbg]

Zitat:

Zitat von win568

Cool. Dank da recht. Die Nummer ist 75738.

Jetzt muss ich nochmal nachfragen. Hast du das ganze auch unter Delphi 2007 mit installiertem DelphiSpeedUp 2.8 getestet? Womöglich ist das sogar die Lösung des Problems. In dem Fall könnte ich ed sicherlich einrichten, für Delphi 2009 und 2010 einen Patch rauszubringen.

Aus wievielen Units besteht denn das Projekt?

[cookie22]

hallo,

ich habe ein merkwürdiges problem mit speedup.

dies problem besteht nur mit delphi 2005 und wenn man sptbxlib installiert hat.

wenn man nun speedup installiert läd delphi beim ersten mal sehr schnell wie man es erwarten würde. startet man delphi dann zum zweiten mal hängt es bis zu 2 minuten bevor es weiter läd.

wenn man jetzt speedup deinstalliert und wieder installiert gehts für einen start schnell. nun frage ich mich, was macht speedup beim zweiten start anders als beim ersten und kann ich das so beeinflussen, dass es immer so wie direkt nach der installation funktioniert. ich glaube es hat was mit der reihenfolge zutun mit der die packete geladen werden.

das passiert übrigens unabhänig von der speedup version habs mit fast allen versionen von 1.9 aufwärts getestet. bei delphi 2006 bzw. delphi 5 und 7 hat sptbxlib keinen einfluss auf die ladezeit.

jemand eine idee wie ich das hinbekommen kann?

gruss,
cookie

[jbg]

Zitat:

Zitat von cookie22

jemand eine idee wie ich das hinbekommen kann?

Auf die Schnelle würde ich sagen, dass es an folgendem code in SpTBXReg.pas liegt.

Delphi-Quellcode:

  {$IFDEF JR_D9}
  ForceDemandLoadState(dlDisable);
  {$ENDIF}

Da ich aber kein Delphi 2005 installiert habe, kann ich das nicht überprüfen.

[win568]

Hi Andi

Unser Projekt besteht aus ~ 14000 Units im Vollausbau und hat ~ 9.5 Mio Locs. Es handelt sich um ein datenbankgestütztes ERP Programm (SQL Server und Oracle). Das ganze Projekt basiert grundsätzlich auf einem MVC Konzept. Die Dateien werden organisatorisch über eigene "Uses" Units der verschiedenen Gruppen (WWS, PPS usw.) eingebunden. Alle Gruppen "Uses" Units werden in einer zentralen Uses Unit in das Projekt eingebunden. Die Kommunikation erfolgt über Interfaces.

Ich habe das ganze mit D2007 und deiner DelphiSpeedUp 2.8 getestet. Leider hat sich hier keine signifikante Geschwindigkeitserhöhung ergeben. Wenn du eine Lösung finden würdest, wäre das für uns natürlich spitze.

[cookie22]

Zitat:

Zitat von jbg

Zitat:

Zitat von cookie22

jemand eine idee wie ich das hinbekommen kann?

Auf die Schnelle würde ich sagen, dass es an folgendem code in SpTBXReg.pas liegt.

Delphi-Quellcode:

  {$IFDEF JR_D9}
  ForceDemandLoadState(dlDisable);
  {$ENDIF}

Da ich aber kein Delphi 2005 installiert habe, kann ich das nicht überprüfen.

jo danke, genau das ist der grund. :)

[jbg]

Der Release Candidate ist die finale Version. Es traten keine weiteren Fehler mehr auf (oder keiner außer mir hat gestest).

Das IDE Fix Pack 2.8 für Delphi 2009 und 2010 enthält nun ebenfalls die Debugger-Optimierung und ein paar Gallileo-IDE relevante Verbesserungen.

[Sanguis]

Hallo,

erstmal: Klasse Tool! Ich hab es lane mit Delpi7 benutzt. Vor einigen Monaten, stieg ich auf BDS2007 um. Leider kann ich TsiLang Expert, unter Tools, nicht mehr nutzen. Beim Aufruf, fommt eine AV in einer BPL. Ohne DSU geht es problemlos. Und ich möchte gern die TsiLangComponents behalten, sie machen vieles einfacher.

Wo ich grad hier bin: Welche Tools, für die IDE, könnt ihr noch empfehlen? Außer Geexpert, finde ich noch nichts nützliches.

Gruß,
Andy

[mkinzler]

Die CnWizards

[Sanguis]

Zitat:

Zitat von mkinzler

Die CnWizards

Wow, geniale Tools! Ich bin begeistert, vielen Dank. Nu muß ich nur noch den CodeFormatierer finden. Aber das mach ich eher morgen früh.

Vielen Dank, wußte nicht, das so viel möglich ist.