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

[jbg]

Übrigens: Als TurboExplorer vor 2 Jahren raus kam und man die damals aktuelle DelphiSpeedUp Version installierte, hatte man (bis auf den fehlenden Kommandozeilen-Compiler) eine voll funktionierende IDE. Erst einen Tag danach fügte ich Code hinzu, der die Sperre aufrecht erhielt. Nur hat sich eben im Laufe der Jahre viel an DSU geändert und da man kein BDS 2006 und TE 2006 gleichzeitig installiert haben kann, habe ich die Änderungen nicht mehr getestet.

[toms]

Zitat:

Zitat von Larsi

[OT] Jetzt alle schnell nochmal die alte Datei downloaden bis Sie geändert wurde :) [OT]

Da hatte ich das Glück, dass ich noch die alten Daten erwischt habe *g*
Aber ich arbeite ja nicht mit dem TE...

[jbg]

Zitat:

Zitat von toms

Da hatte ich das Glück, dass ich noch die alten Daten erwischt habe *g*

Das das funktioniert, hängt ganz allein davon ab, in welcher Reihenfolge die Package geladen werden. Ist also nicht wirklich stabil, wenn man eigene Packages einhängt.

[Larsi]

Wie in welcher Reihenfolge? Einfach TD downloaden die von mir genannte Datei ausführen und Spass haben :)

[Larsi]

Gestern hast du geschrieben dass die längst geändert wurden aber du kannst doch nicht in diesre Nacht schon wieder 200 Downloads haben oder?

[Namenloser]

Also ich hab mir gerade DelphiSpeedUp 2.75 heruntergeladen und es klappt immer noch.
Vielen Dank :mrgreen:

[Larsi]

Nee geht nicht mehr leider :( Es wird zwar noch installiert und man kann auch noch dieses Prozess sofort beenden oder so im Menü unter Beenden klicken aber die Indys sind bei mir nicht mehr da, bei dir?

[Namenloser]

Wie gesagt, bei mir sind sie seit 5 Minuten da, und schneller ist die IDE auch noch. Hab die Version aus dem ersten Beitrag hier genommen.

[Larsi]

Ok dann hat jbg wohl n kleinen Fehler gemacht :)

[Larsi]

Ich glaube es ist echt besser wenn die Datei erstmal von nem Mod gesperrt sonst kircht jbg noch Probleme mit irgendwelchen Codegear Leuten^^

[jbg]

Zitat:

Zitat von Larsi

Ich glaube es ist echt besser wenn die Datei erstmal von nem Mod gesperrt sonst kircht jbg noch Probleme mit irgendwelchen Codegear Leuten^^

Ich frage mich gerade, welche Dateien ihr euch heruntergeladen habt (und wann). Ich habe gerade alle Downloads nochmal gecheckt, und bei keinem funktioniert die "Freischaltung" der Indys.

[Namenloser]

Ich habe " Version 2.75 - all in one (5 bis 2007)" aus dem ersten Beitrag heruntergeladen und dann die "InstallDelphiSpeedUp10.exe" ausgeführt. TurboDelphi neugestartet und die Indys waren da. DDev konnte ich auch installieren.

[jbg]

Zitat:

DDev konnte ich auch installieren.

Du besitzt ja auch die originale Turbo Explorer Version und nicht die nachgeschobene, die keine IDE Experten mehr laden kann.

[Namenloser]

Hmm, also ich weiß nicht. Die älteren DSU-Versionen konnte ich nicht installieren. Naja ist ja auch (mir zumindest) egal.

[Larsi]

Also mit der Version die gestern noch up war war halt einmal ein paar Zusatzfunktionen und halt die indys. bei der neuen sind nur noch die zusatzfunktionen da aber die indys nicht mehr. Obwohl auch das bestimmt nicht gerne gesehen wird :)

[jbg]

Zitat:

Zitat von Larsi

Obwohl auch das bestimmt nicht gerne gesehen wird :)

CodeGear hätte halt nie die originale TE herausbringen dürfen, in der IDE Experten geladen werden konnten. Ich kann meine Software ja nicht so programmieren, dass zukünftige Einschränkungen nicht umgangen werden können. DSU hatte die Package Einschränkung damals schon ausgehebelt und ich habe (aus eigenem Willen) dann DSU verändert. Nur im Laufe der Jahre habe ich mich nicht mehr um die TurboExplorer Versionen geschert, und mich auf die Optimierung konzentriert. Man baut auch nicht die Package-Sperre in die Package-Ladefunktion ein, sondern davor. Vor allem lädt man das Package nicht erst, um es dann wieder zu entladen wenn das Package nicht von CodeGear freigeschaltet ist.

[jbg]

Da hat doch glatt jemand noch einen Bug oder besser gesagt ein Speicherleck in DelphiSpeedUp gefunden. Dieses Speicherleck ist so groß (64 KB per geladene DLL/BPL), dass ich mich spontan entschlossen habe eine neue DelphiSpeedUp Version 2.76 zu veröffentlichen. Auf meinem System nimmt dieses Leck mehr als 30 MB in Anspruch, die nach dem Laden der IDE einfach nur noch "dumm herumstehen".

Den Download gibt es wie üblich auf der ersten Seite dieses Threads, von der DelphiSpeedUp Homepage oder von CodeGears CodeCentral

[STS301]

Delphi startet jetzt deutlich schneller als mit 2.75

[jbg]

Zitat:

Zitat von STS301

Delphi startet jetzt deutlich schneller als mit 2.75

Gut zu wissen. Mit meinem (neuen) Rechner kann ich keinen Geschwindigkeitsunterschied mehr feststellen. Bei dem überholt sich die IDE selbst beim Starten.

[STS301]

aber bei meinem Rechner braucht Delphi 6 (mit 6 3rd Komponenten) und durchschnittlicher rechnerbelastung rund eine halbe Minute (ohne Speedup)

[Namenloser]

Dank der neuen DSU-Version braucht TurboDelphi nur noch 6-7mb Arbeitsspeicher (direkt nach dem Starten). Früher war es niemals weniger als 25 mb. War das so ein fettes Speicherloch, das du da geschlossen hast? :shock:

[edit]700. Beitrag im Thema. Hab ich jetzt was gewonnen? :stupid:[/edit]

[DeddyH]

Zitat:

Zitat von NamenLozer

[edit]700. Beitrag im Thema. Hab ich jetzt was gewonnen? :stupid:[/edit]

Du nicht, wenn, dann STS301 :stupid:

[mkinzler]

Er hat wohl den ursprünglichen Beitrag von Andreas nicht mit gerechnet.

[DeddyH]

Na gut, so gesehen...

[Namenloser]

Also die Startseite meinte 700 Beiträge Antworten.

[jbg]

Zitat:

Zitat von NamenLozer

War das so ein fettes Speicherloch, das du da geschlossen hast?

Wenn man bedenkt, dass BDS mehr als 400 DLLs lädt, und für jede ein Speicherleck von 64 KB auftritt, dann ergibt das recht schnell 25 MB Speicherverschwendung.

[FAlter]

Hi,

ich kann auch bestätigen, dass es jetzt nochmals schneller geworden ist (D7 und noch mehr D2k5, 2533 MHz, 1536 MB, beide Male JVCL dabei und ein paar andere Fremdkomponenten). Auf den Speicher hab ich nie genau geachtet, und bei D2k5 PE gibt es eh jede Menge Speicherlecks.

Mfg
FAlter

[Garfield]

Zitat:

Zitat von FAlter

Auf den Speicher hab ich nie genau geachtet, und bei D2k5 PE gibt es eh jede Menge Speicherlecks.

Turbo Delphi auch. Wenn man beim Ändern einen gewissen Punkt überschritten hat, kann man im Task Manager zusehen, wie Turbo Delphi immer mehr Speicher belegt, ohne das man etwas tut.

[Namenloser]

Ich versteh immer noch nicht, warum CodeGear es nicht schafft, das ganze BDS stabil zu programmieren. Die haben schließlich den Source Code - im Gegensatz zu jbg. Irgendwie ist es doch erbärmlich, dass es sowas wie DSU überhaupt geben muss bzw man sich schon dran gewöhnt hat, dass eifnach so während des Arbeitens oder auch ohne, dass man irgendwas tut, plötzlich irgendwelche internen Fehler auftreten, die es einem nicht mal mehr erlauben, die Änderungen zu speichern.

Übrigens:
Neulich war das bei mir echt aufregend: Urplötzlich kam ein interner Fehler, der nach dem Schließen der Meldung gleich wieder kam. Ich hab dann durch gelangweiltes Gedrückthalten von Enter festgestellt, dass ich ab und zu Lücken erwischen konnte, in denen für ganz kurz keine Fehlermeldung sichtbar war, sodass die Tastendrücke zur IDE ins Codefenster durchdrangen. Mit langem Gedrückthalten von Alt+F4 hab ich so das "Änderungen Speichern?"-Fenster provozieren können. Das Schwierige daran war natürlich, im richtigen Moment noch Enter zu drücken, weil sich der Dialog mit Alt+f4 natürlich auch wieder schließt. Am Ende hab ich's dann tatsächlich noch geschafft, die Änderungen zu speichern. Gut, dass ich nicht beruflich damit arbeite. :roll:

[alzaimar]

Zitat:

Zitat von NamenLozer

Ich versteh immer noch nicht, warum CodeGear es nicht schafft, das ganze BDS stabil zu programmieren. Die haben schließlich den Source Code

[X] Du hast noch kein komplexes System implementiert.

[Namenloser]

Behaupte ich auch nicht. Ich bin aber auch 1. Schüler, 2. eine Einzelperson und hab 3. nicht Informatik studiert. Außerdem muss es ja wohl möglich sein, das System intern zu entschlacken, wenn eine externe DLL das kann.

Edit: 4. Ich verdiene übrigens auch nicht mein geld damit.

[Garfield]

Zitat:

Zitat von alzaimar

[X] Du hast noch kein komplexes System implementiert.

Darf man deshalb Fehler mitschleppen ohne sie zu beseitigen? Kann natürlich auch sein, dass das Auftreten bestimmter Fehler hardwareabhängig ist.

[alzaimar]

Zitat:

Zitat von Garfield

Zitat:

Zitat von alzaimar

[X] Du hast noch kein komplexes System implementiert.

Darf man deshalb Fehler mitschleppen ohne sie zu beseitigen? Kann natürlich auch sein, dass das Auftreten bestimmter Fehler hardwareabhängig ist.

[X] Du auch nicht :mrgreen:

[MaBuSE]

Zitat:

Zitat von alzaimar

Zitat:

Zitat von Garfield

Zitat:

Zitat von alzaimar

[X] Du hast noch kein komplexes System implementiert.

Darf man deshalb Fehler mitschleppen ohne sie zu beseitigen? Kann natürlich auch sein, dass das Auftreten bestimmter Fehler hardwareabhängig ist.

[X] Du auch nicht :mrgreen:

Ihr seid völlig offTopic :mrgreen:

@jbg: Danke für DSU. (Das wollte ich nochmal loswerden.)

Mich würde mal interessieren, ob Du bei Deinen Caching (ExpandFileName cache, FileAgeCache, ...) "nur" die Dateien auf der Platte cachest, oder auch die Dateien, die im TIVirtualFileSystem abgelegt (und noch nicht gespeichert) sind?
Kann man irgendwo Einzelheiten lesen was Du wie gemacht hast (und warum)?
(Nicht das ich das bräuchte oder wissen müsste, aber ich bin halt neugierig ;-))

[Garfield]

Zitat:

Zitat von alzaimar

[X] Du auch nicht :mrgreen:

Wir alle nicht. :thumb:

Zitat:

Zitat von MaBuSE

Ihr seid völlig offTopic :mrgreen:

Dann sollten wir damit aufhören. :wink:

[jbg]

Zitat:

Zitat von Garfield

Wir alle nicht. :thumb:

Bitte nicht von sich selbst auf andere schließen :-)

Zitat:

Zitat von MaBuSE

Mich würde mal interessieren, ob Du bei Deinen Caching (ExpandFileName cache, FileAgeCache, ...) "nur" die Dateien auf der Platte cachest

Es wird nur die Auflösung des Dateinamen gecache. Und um es genauer zu sagen, der ExpandFileName Cache ist mittlerweile wieder ausgebaut. Es ist nur noch eine Prüfung auf Leerstring vorhanden, da der nicht nach Unicode konvertiert werden muss, bevor dann die Unicode Version von ExpandFileName feststellt, dass ja gar nichts zu tun ist.
Die FileAge Aufrufe werden nur beim Start der IDE gecachet, so dass pro Datei nur einmal auf die Platte zugegriffen wird. Danach wird der Cache aber wieder abgeschaltet, weil es sonst zu Fehlern kommen könnte. Der Compiler cachet ja selbst auch noch.

[Garfield]

Zitat:

Zitat von jbg

Bitte nicht von sich selbst auf andere schließen :-)

:gruebel:

Du bist doch anscheinend der selben Meinung:

Zitat:

Zitat von jbg

... dass ich mich spontan entschlossen habe eine neue DelphiSpeedUp Version 2.76 zu veröffentlichen. ...

[smallsmoker]

kp ob das schon jemand geschrieben hatt aber bei mir verschwinden die icons von ein paar nonvisual komponenten bspw.: dem timer oder den sockets ..
os: vista ultimate x64
ide: codegear rad 2007

[jbg]

Zitat:

Zitat von Garfield

Zitat:

Zitat von jbg

Bitte nicht von sich selbst auf andere schließen :-)

:gruebel:

Ich würde DelphiSpeedUp jetzt nicht gerade als komplexe Anwendung bezeichnen. Es ist mehr eine Ansammlung von optimierten Funktionen.

[jbg]

Zitat:

Zitat von smallsmoker

kp ob das schon jemand geschrieben hatt aber bei mir verschwinden die icons von ein paar nonvisual komponenten bspw.: dem timer oder den sockets ..
os: vista ultimate x64
ide: codegear rad 2007

Das ist ein Bug von Delphi 2006 und 2007. Kommt durch das möchtegern Caching der IDE. Das hat aber mit diesem Thread nun wirklich nichts zu tun. (Und nein, den Bug kann ich nicht beheben)