Stringfunktionen

[relocate]

Gibt es irgendwo eine Sammlung erweiterter Stringfunktionen?

Hintergrund: Mit D5 habe ich nicht einmal StrUtils, wobei ich auch nicht weiß, ob dort etwas enthalten ist, was D5 nicht anderweitig kennt, außer vielleicht PosEx.

Worum es mir aber geht sind erweiterte/spezielle Stringfunktionen die nicht zum Standardrepertoire von Delphi gehören (zumindest in D5 noch nicht).

Zum Beispiel eine Explode Funktion/Prozedur:
http://forum.delphi-treff.de/showthr...rings-zerlegen

oder die Anzahl eines Zeichens in einem String ermitteln.
Bei einer Suche im Internet finde ich bei diversen Schlagwörtern nur ein Hinweis auf die Length Funktion die mir ja die Anzahl aller Zeichen ausgibt, das aber nicht das ist was ich suche. Oder aber die Ermittlung eines Zeichens in einem String, was ja Pos macht, aber das ist auch nicht das was ich benötige.

Ja, ich kann/könnte es selbst programmieren, aber
1. Wird meine Variante nicht unbedingt die schnellste sein, da ich kein Profi Entwickler bin
2. Gibt es mit Sicherheit schon mehrere Implementationen, auch wenn die vielleicht erst auf der Googlesuchseite 10 steht.
3. Weiß ich dann immer noch nicht, welche die Schnellste ist.

Nicht nur in dem Bereich wäre also eine Sammlung interessant die
mehrere Lösungen präsentiert und dies vielleicht sogar mit Performenzangaben je nach Verwendungszweck.

Wie dem auch sei.
Für den aktuellen Zweck habe ich etwas gefunden:
http://www.delphipraxis.net/116372-a...ermitteln.html
Auch wenn die zweite Antwort Nonsens ist, weil die Frage nicht verstanden wurde, bzw. hier:
http://www.delphipraxis.net/85075-wi...em-string.html
muss nur mal sehen welche die bessere Variante ist.

Wenn jemand also eine Sammlung von Stringfunktionen kennt, das wäre super.

Gruß relocate

PS: Vor dem Posten bitte auch prüfen, ob der Link aus den Favoriten noch aktuell ist. Habe Links auf Stringfunktionen gefunden, leider waren die nicht mehr Online.

[Iwo Asnet]

Explode: Such mal hier im Forum.
Ansonsten: Viele Programmierer in diesem Forum freuen sich, dir die schnellste Routine frei Haus zu liefern. Und etwas dazulernen kannst du auch.

Aber: Du musst immer eine Lösung vorweisen, die andere verbessern sollen, denn sonst denkt man, Du lässt andere für dich arbeiten. Das kommt nicht gut an.

Also: Ran ans Werk!

[Namenloser]

FastCode hat ein paar auf Geschwindigkeit optimierte String-Funktionen, unter anderem PosEx, aber so High-Level-Sachen wie Explode sind nicht dabei. Keine Ahnung, ob es dir weiterhilft... eine reine String-Library kenne ich nicht.

[Iwo Asnet]

Na gut, was zum anfixen:

http://www.koders.com/delphi/fidFB38...FDF60E6C7.aspx

Eigentlich von www.droopyeyes.com, aber die sind gerade off.

[Bummi]

@Iwo Asnet

Ein Hinweis für unerfahrene 2009+ Anwender, sollte noch gegeben werden

[relocate]

Zitat:

Zitat von Iwo Asnet (Beitrag 1163348)

Explode: Such mal hier im Forum.
Ansonsten: Viele Programmierer in diesem Forum freuen sich, dir die schnellste Routine frei Haus zu liefern. Und etwas dazulernen kannst du auch.

Das ist mir klar. Es sollte immer eine Freude sein. *hö*
Also. Ich bin jemand, der gerne alles selbst entwickelt und finde es ätzend, wenn immer auf irgendwelche Komponenten verwiesen werden. Mit der Programmierung habe ich unter TP 6 angefangen, eigentlich TP3 aber TP6 gab es schon, die Schule war nur noch nicht auf dem neuesten Stand. Folglich musste man so ziemlich alles selbst entwickeln. Dann habe ich eine andere Richtung eingeschlagen und bin was das Programmieren angeht nach einer Pause beim Hobby geblieben.
Da aber solche grundlegenden Routinen (auch wenn ich sie als "erweiterte" Funktionen bezeichnet habe), ist es keine Superduperkomponente nach der ich gefragt habe, die sich als Eierlegendewollmichsau entpuppt, noch habe ich verlangt, die Lösung hier auf dem silbernen Tablett zu bekommen, und diese Routinen zu Hauf im Netz zu finden sind und man nicht wirklich immer wieder das Rad (das Rad, nicht das Auto) neu entwickeln muss, so habe ich nur gefragt, ob jemand eine Sammlung kennt, da die Suche zeitraubend ist und für solche Basisaufgaben eine Sammlung echt super wäre. Explode war nur ein Beispiel und meine eigentliche Suche nach Counterfunktion war schon von Erfolg gekrönt.

Zitat:

Zitat von Iwo Asnet (Beitrag 1163348)

Aber: Du musst immer eine Lösung vorweisen, die andere verbessern sollen, denn sonst denkt man, Du lässt andere für dich arbeiten. Das kommt nicht gut an.

Also: Ran ans Werk!

Man kann auch durch Codebeispiele lernen, es ging hier auch nicht um die ersten zarten Programmierschritte. Und eigentlich auch nicht um irgendeine explizite Lösung für ein Problem, sondern es ging hauptsächlich darum ob es so eine Sammlung gibt.
Außerdem bin ich gerne bereit meinen Beitrag für eine solche Sammlung zu leisten, ich habe z.B. eine Delimiter Funktion entwickelt, die ich bislang nicht finden konnte, auch wenn es sie geben mag, aber ich will sich eben nicht irgendwo posten wo sie einsam und verloren untergeht, sondern gerne in eine Sammlung mit vielen anderen Stringfunktionen.

[relocate]

Zitat:

Zitat von NamenLozer (Beitrag 1163350)

FastCode hat ein paar auf Geschwindigkeit optimierte String-Funktionen, unter anderem PosEx, aber so High-Level-Sachen wie Explode sind nicht dabei. Keine Ahnung, ob es dir weiterhilft... eine reine String-Library kenne ich nicht.

Hey, das ist ja was. Über Fastcode habe ich schon was gesehen, aber die Seite auf die verwiesen wurde: http://www.fastcodeproject.org/ ist nicht mehr das, was sie wohl mal war, deshalb der Hinweis die Aktualität zu prüfen. Es scheint ja in höheren Delphifunktionen ja schon eingebaut zu sein. Das ist auch so ein Grund. Die Benutzer dieser Versionen bekommen ja alles schon Frei Haus, aber die Hobbyentwickler mit ihren alten Versionen stehen auf dem Schlauch.
Explode war ja nicht wirklich meine Suche, aber selbst das würde ich nicht als Highlevel bezeichnen. Luckie hat so etwas in seinen Snippets: http://www.michael-puff.de/Programmi.../Explode.shtml eher schon eine Explode Variante die in einem Schlag nach mehreren Separatoren trennen kann, was man sich dann ja wirklich mit einer Basisexplodevariante schnell bauen kann. Okee, die Assemblerversion ist dann schon wirklich was für Experten.

Danke.

[relocate]

Zitat:

Zitat von Iwo Asnet (Beitrag 1163353)

Na gut, was zum anfixen:

http://www.koders.com/delphi/fidFB38...FDF60E6C7.aspx

Eigentlich von www.droopyeyes.com, aber die sind gerade off.

Mehr als zum anfixen ist es wohl nicht, wenn die Droopyeyes down sind, aber das hier im Kopf der Unit steht:

//No copying, alteration, or use is permitted without
//prior permission from myself.

Dann darf man das wohl kaum verwenden.

[relocate]

EDIT:\\ Doppelpost, wenn der Browser mal wieder hängt.

[UliBru]

JCLStrings ?
Eigene Beiträge sind vermutlich ab einer bestimmten Qualität sicher machbar. Siehe auch hier

[relocate]

Zitat:

Zitat von Bummi (Beitrag 1163354)

@Iwo Asnet

Ein Hinweis für unerfahrene 2009+ Anwender, sollte noch gegeben werden

Dann mal her mit dem Hinweis, auch wenn ich kein unerfahrener und kein Anwender von 2009+ bin.

[shmia]

Die Jedi Code Library enthält umfangreiche Stringfunktionen und Vieles anderes mehr. :thumb:
Ich verwende unter D5 noch die Version 1.0.4, weil ich mit den (damals) neuen 2.0x Versionen Probleme hatte.
Auf jeden Fall erhälst du mit der JCL ein volles Paket an Units mit vielen nützlichen Funktionen.
Dein Programm wird dabei kaum grösser, weil der Linker nur die Funktionen dazulinkt, die du auch benützt hast.

[relocate]

Zitat:

Zitat von UliBru (Beitrag 1163363)

JCLStrings ?
Eigene Beiträge sind vermutlich ab einer bestimmten Qualität sicher machbar. Siehe auch hier

Tolle Unit, aber die Assemblerumsetzungen sind denn eher nicht zum lernen geeignet. Eine fertige Unit meinte ich eben nicht mit einer Sammlung, schon eine aus der man lernen kann. Und die JCL erschlägt einen sowieso.

[relocate]

Zitat:

Zitat von shmia (Beitrag 1163365)

Die Jedi Code Library enthält umfangreiche Stringfunktionen und Vieles anderes mehr. :thumb:
Ich verwende unter D5 noch die Version 1.0.4, weil ich mit den (damals) neuen 2.0x Versionen Probleme hatte.
Auf jeden Fall erhälst du mit der JCL ein volles Paket an Units mit vielen nützlichen Funktionen.
Dein Programm wird dabei kaum grösser, weil der Linker nur die Funktionen dazulinkt, die du auch benützt hast.

Bei den fetten Programmen mit der VCL (zumindest in D5) spielt das wohl kaum eine Rolle, aber bei meinen NonVCL Anwendungen nicht verkehrt. Guter Hinweis mit den Versionsproblemen (noch so ein Ding was mich von fertigen Komponenten/Units abschreckt).

[himitsu]

Zitat:

1. Wird meine Variante nicht unbedingt die schnellste sein, da ich kein Profi Entwickler bin
2. Gibt es mit Sicherheit schon mehrere Implementationen, auch wenn die vielleicht erst auf der Googlesuchseite 10 steht.
3. Weiß ich dann immer noch nicht, welche die Schnellste ist.

Wobei es ja auch nicht immer um Schnelligkeit geht.

Denn es kommt auf den Einsatzzweck drauf an.
- wird es sehr oft aufgerufen, dann könnte es schon wichtig sein
- ist die zeit egal, dann ist auch die Geschwindigkeit egal (bzw. es muß nicht unbedingt das Allerschnellste sein)
- und manchmal reicht es, wenn es ausreichend flott ist, aber man dafür wartbaren code bekommt, welchen man eventuell auch noch selber versteht.

Ansonsten kannst du ja immernoch nachmessen, bzw. etwas nehmen, was dir vom Code her gefällt und sollte es doch noch geschwindigkeitsprobleme geben, dann könnte man immer noch nachsehn was schneller/optimaler ist.



Wie es schon erwähnt wurde:
Wenn es um einzelne Funktionen geht, dann bieten die Forensuche, die CL, sowie Google und die anderen Delphi-Webseiten sehr viel.
Und notfalls fragt man eben hier geziehlt nach.

[DeddyH]

Zunächst muss eine Routine zuverlässig funktionieren, danach kann man dann sehen, wie man die Geschwindigkeit ggf. erhöhen könnte. Dreht man diese Reihenfolge um, kommt selten etwas Brauchbares dabei heraus.

Zitat:

Zitat von Donald Knuth

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil

[relocate]

Zitat:

Zitat von himitsu (Beitrag 1163373)

Zitat:

1. Wird meine Variante nicht unbedingt die schnellste sein, da ich kein Profi Entwickler bin
2. Gibt es mit Sicherheit schon mehrere Implementationen, auch wenn die vielleicht erst auf der Googlesuchseite 10 steht.
3. Weiß ich dann immer noch nicht, welche die Schnellste ist.

Wobei es ja auch nicht immer um Schnelligkeit geht.

Denn es kommt auf den Einsatzzweck drauf an.

Das hatte ich ja auch geschrieben, nicht unterschlagen beim Zitieren. :-D

"Nicht nur in dem Bereich wäre also eine Sammlung interessant die
mehrere Lösungen präsentiert und dies vielleicht sogar mit Performenzangaben je nach Verwendungszweck."

Zitat:

Zitat von himitsu (Beitrag 1163373)

- wird es sehr oft aufgerufen, dann könnte es schon wichtig sein
- ist die zeit egal, dann ist auch die Geschwindigkeit egal (bzw. es muß nicht unbedingt das Allerschnellste sein)
- und manchmal reicht es, wenn es ausreichend flott ist, aber man dafür wartbaren code bekommt, welchen man eventuell auch noch selber versteht.

Das ist der Fall, bzw. kann immer der Fall sein, weshalb der optimale Algorithmus (was auch immer das dann sein mag) immer gut wäre. Im Fall einer Sammlung ja auch gut zu wissen und bei Quick and Dirty kann es schon bei einem Aufruf "extreme" Unterschiede geben. Und eine Quick and Dirty Variante kann unter Umständen komplizierter und schwer verständlicher sein, als eine optimierte Variante.

Zitat:

Zitat von himitsu (Beitrag 1163373)

Ansonsten kannst du ja immernoch nachmessen, bzw. etwas nehmen, was dir vom Code her gefällt und sollte es doch noch geschwindigkeitsprobleme geben, dann könnte man immer noch nachsehn was schneller/optimaler ist.

Wie es schon erwähnt wurde:
Wenn es um einzelne Funktionen geht, dann bieten die Forensuche, die CL, sowie Google und die anderen Delphi-Webseiten sehr viel.
Und notfalls fragt man eben hier geziehlt nach.

Klar, aber bei einer Sammlung wäre es dann schon schön, wenn man so etwas dabei stehen hat, mit einem Beispiel. Tja, da ist eben das Problem, man muss sich aus allen Ecken und Enden was zusammen suchen, was eigentlich zusammen gehört. Das Problem mit Google habe ich schon angegeben, das Ergebnis passt nicht immer auf die Suche, immer seltener wie ich finde. Und auch die Code Library hier ist nicht sehr optimal geordnet. Und gefragt habe ich, aber sowas führt zu immer mehr Einträgen die eigentlich schon beantwortet sind und zu immer mehr überladenen Ergebnissen bei Suchmaschinen.

[relocate]

Zitat:

Zitat von DeddyH (Beitrag 1163374)

Zunächst muss eine Routine zuverlässig funktionieren, danach kann man dann sehen, wie man die Geschwindigkeit ggf. erhöhen könnte. Dreht man diese Reihenfolge um, kommt selten etwas Brauchbares dabei heraus.

Klar, Zuverlässigkeit steht an erster Stelle, leider leidet die Effizienz immer mehr, die neue Hardware bügelt das ja schon aus.

Ich habe mal ein Char aus einem String herausgelöst. Was bei einem Leerstring eine Exception wirft, also muss das getestet werden. Ich habe das mit folgenden Varianten gemacht:

1)

Delphi-Quellcode:

if wort = '' then chrtest := #0
else chrtest := wort[1];

2)

Delphi-Quellcode:

if wort <> '' then chrtest := wort[1]
else chrtest := #0;

3)

Delphi-Quellcode:

if length(wort)=0 then chrtest := #0
else chrtest := wort[1];

4)

Delphi-Quellcode:

if length(wort)>0 then chrtest := wort[1]
else chrtest := #0;

5)

Delphi-Quellcode:

try 
  chrTest := wort[1];
except
  chrTest := #0;
end;

Auf meinem PC war die Variante 2 die schnellste, wenn auch nur unwesentlich schneller als 1.
Variante 4 hat ungefähr doppelt solange gedauert, wiederum unwesentlich schneller als 3.
Der Try Block etwas langsamer noch als 3/4 (außer die Exception wurde geworfen, das hat gedauert).

Wenn der Fall eintrat dass der String leer war erhöhte sich die Abarbeitungszeit.

Auf einem anderen, älteren PC war das anders. Die Variante 1 und 2 wurden deutlich schneller bei einem Leerstring. Und die Varianten 3 und 4 etwas schneller. Also ist auch noch relevant wie man testet und welcher der Ziel PC ist. Der Try Block war auch da langsamer bei einer Exception.

[himitsu]

Zitat:

Delphi-Quellcode:

try
  chrTest := wort[1];
except
  chrTest := #0;
end;

Sowas sollte man auch niemals machen.
Denn fang jetzt mal an dein Programm zu debuggen, wenn da genügend solcher Code drin vorkommt,
dann kannst'e dich auch gleich erschießen, denn sowas macht absolut keinen Spaß mehr.

Im Fall von Zahlen ist das sehr gut beobachtbar:

Delphi-Quellcode:

try
  i := StrToInt(s);
except
  i := 0;
end;

// oder

i := StrToIntDef(s, 0);

Delphi-Quellcode:

try
  i := StrToInt(s);
  {mach was mit i}
except
end;

// oder

if TryStrToInt(s, i) then
  {mach was mit i}

Vorallem leere except-end-Blöcke sind grauenhaft.


Bezüglich der Unterschiede zwischen = und <>.
Dort hängt es sehr von den Eingangsdaten ab.
Da ist mir persönlich fast immer alles egal und ich verwende die Variante, welche ich besser lesen kann. Außerdem versuche ich durchgängig nur eine Variante zu verwenden, weil man den gesamten Code dadurch auch besser verstechen kann. (man verliest sich weniger)

[relocate]

Zitat:

Zitat von himitsu (Beitrag 1163382)

Zitat:

Delphi-Quellcode:

try
  chrTest := wort[1];
except
  chrTest := #0;
end;

Sowas sollte man auch niemals machen.
Denn fang jetzt mal an dein Programm zu debuggen, wenn da genügend solcher Code drin vorkommt,
dann kannst'e dich auch gleich erschießen, denn sowas macht absolut keinen Spaß mehr.

Ich bin auch kein Freund von den Try-Blöcken. Ich hatte ja geschrieben, ich kam von Turbo Pascal 6, da gab es solche feinen Sachen noch nicht. Na ja, nicht direkt. Da musste z.B. die I/O Kontrolle ausgeschaltet werden und über IOResult das Ergebnis abgefragt. Ist quasi ein Try Except Block. Aber in diesem Fall funktioniert es ja. Ich kam darauf, weil ja eine Exception stattfand, also konnte es damit abgefangen werden. Allerdings finde ich, wer das so nutzt ist zu Faul sauber zu programmieren. In manchen Fällen wohl aber nicht zu vermeiden.

Zitat:

Zitat von himitsu (Beitrag 1163382)

Im Fall von Zahlen ist das sehr gut beobachtbar:

Delphi-Quellcode:

try
  i := StrToInt(s);
except
  i := 0;
end;

// oder

i := StrToIntDef(s, 0);

Delphi-Quellcode:

try
  i := StrToInt(s);
  {mach was mit i}
except
end;

// oder

if TryStrToInt(s, i) then
  {mach was mit i}

Vorallem leere except-end-Blöcke sind grauenhaft.

Das mit den Zahlen schaue ich mir mal an, habe mir das aber mit dem Code den ich gepostet habe auch gemacht. Ich fand jetzt die Abfrage nach ='' so billig :lol: mit Length hat mehr Stil, ich benutze aber trotzdem ='' und das mit den leeren Except Blöcken ist logisch.

Zitat:

Zitat von himitsu (Beitrag 1163382)

Bezüglich der Unterschiede zwischen = und <>.
Dort hängt es sehr von den Eingangsdaten ab.
Da ist mir persönlich fast immer alles egal und ich verwende die Variante, welche ich besser lesen kann. Außerdem versuche ich durchgängig nur eine Variante zu verwenden, weil man den gesamten Code dadurch auch besser verstechen kann. (man verliest sich weniger)

In diesem Fall gab es ja kaum Zeitunterschiede, aber auch das ist klar. Man prüft besser auf den Sonderfall und den Standardfall lässt man so durch gehen (ich habe es irgendwo besser formuliert stehen).

[himitsu]

Delphi-Quellcode:

s <> ''

und

Delphi-Quellcode:

s = ''

prüft theoretisch auf die globale Konstante eines Leerstrings ''.
Da ein Leerstring aber einem nil entspricht, ergibt das somit eine Prüfung auf nil, bzw. 0.

Das Length ist eine Funktion und die will erstmal aufgerufen werden, also Sprung (JMP) + Rücksprung (RET), dazu noch eine IF-Abfrage und bis zu zwei ausgelesene Werte (der interne Pointer und die Längenangabe). Erst danach kommt dann deine

Delphi-Quellcode:

=0

-Prüfung dran.

Try selber ist schon OK und vorallem mit Try-Finally sollte man seinen Speicher besser mal sauber halten (Resourcenschutzblöcke).
Auch das Try-Except hat etwas Gutes an sich, aber man sollte es auch ordentlich einsetzen, aber insbesondere nicht zur Ablaufsteuerung.
Eine Exception Ausnahme sollte eine Ausnahme bleiben und nicht grob fahrlässig im Übermaß missbraucht werden.

[Namenloser]

Zitat:

Zitat von himitsu (Beitrag 1163389)

Eine Exception Ausnahme sollte eine Ausnahme bleiben und nicht grob fahrlässig im Übermaß missbraucht werden.

Indy, I’m looking at you. SCNR

[relocate]

Zitat:

Zitat von himitsu (Beitrag 1163389)

Delphi-Quellcode:

s <> ''

und

Delphi-Quellcode:

s = ''

prüft theoretisch auf die globale Konstante eines Leerstrings ''.
Da ein Leerstring aber einem nil entspricht, ergibt das somit eine Prüfung auf nil, bzw. 0.

Würde das gehen, sähe das besser aus im Quellcode. Was letztendlich aber egal ist. Es ist klar, dass der Aufruf einer zusätzlichen Funktion length() Zeit kostet. Es ging ja auch nur darum mögliche Varianten zu testen. Und so ist es eben, wenn man ggf. nicht weiß, welcher Weg optimal ist, kann Zeit verlieren. Wenn man kann, nutzt man Assembler, wenn man weiß, was man tut, kann man wohl kaum schneller werden, auch wenn Delphi schon versucht zu optimieren, wenn der Programmierer einen verqueren Weg geht, kann Delphi auch nicht mehr viel ausrichten.

Vielleicht kannst Du das erhellen. Was ich bei dem Try-Finally manchmal nicht verstehe. Beim erzeugen von Objekten soll es ja genutzt werden und im Finally steht dann die Freigabe des Objekts. Doch es soll ja mit dem Objekt gearbeitet werden und später irgendwann mal freigegeben werden, was nutzt da zu Beginn des Objektlebens ein Finally?

Mit dem Nichteinsetzen zur Ablaufsteuerung gehe ich voll konform.

[himitsu]

Wobei Assembler nicht die eierlegende Wollmilchsau ist, wofür man sie oftmals hält.

Ich hatte persönlich auch schon den Fall, daß ich mit Assembler absolut nichts optimieren konnte.
Es war nahezu genauso schnell, wie ein ordentlicher Pascal-Code und die Codeoptimierung des Compilers.
Abgesehn davon, daß man dem Assembler-Code nicht mehr ansehn konnte, was er eigentlich macht. (ohne tausende Kommentare)

Selbst wenn es ein bissl schneller sein währe, sollte man oftmals wirklich mehr an einen einfach und wartbaren Code denken.
Und jetzt vorallem auch noch in Bezug auf Multiplattform, denn der Pascalcode kann leichter an andere Systeme angepaßt werden, falls er es sowieso nicht schon ist.

Oftmals werden Objekte und andere Resourcen nur für eine gewisse Dauer benutzt.
z.B. der Zugriff auf eine Datei. Da sollte das Dateiobjekt und vorallem das interne Handle am Ende unbedingt freigegeben werden.
Genauso ein Speicherblock (GetMem), welcher benutzt und sicher freigegeben werden sollte, selbst wenn mal etwas nicht so läuft, wie es soll.
Wenn das öfters passiert, dann können einem ganz schnell die Resourcen ausgehn, bzw. die Datei ist beim nächsten Man nicht mehr zugänglich, da sie ja immernoch gesperrt ist.

[relocate]

Ach, na sicher. Inzwischen sind die Compiler so ausgefeilt, dass eine Optimierung in Assembler oftmals kaum noch Sinn macht. Und auch die Portabilität spielt eine große Rolle, wobei das für Delphi bislang eher nebensächlich war. Es wird auch inzwischen nicht einfacher, da sogar der Prozessor versucht den Programmlauf zu optimieren und dabei ggf. anders agiert, als der Entwickler das vorgesehen hat, je nach Prozessortyp.

Das erhellt in der Tat etwas und macht wirklich Sinn. War das unter TP noch einfach als man quasi den ganzen Rechner für sich hatte. Vielen Dank.

[himitsu]

Nja, in dem Fall war halt der Pascal-Code schon sehr gut.
Wobei ich auch erst dachte da noch was rauszuholen.
Nur 3 Tage später übermannte mich dann die Ernüchterung, als es ans Testen des Assemblercodes ging.

3 Tage Arbeit, für nichtmal 100 Millisekunden Zeitersparnis, bei einer Gesamtlaufzeit von knapp 30 Sekunden ... das war's absolut nicht Wert.


Es gibt auch Intelligenzbestien, welche mit Multithreading (das ist auch oftmals überbewertet) Dateioperationen optimieren wollen,
mit dem Ergebnis, daß die Singlethreadanwendung schneller war, da sich die Threads gegenseitig ausbremsten.
Bei HDDs ... SSDs haben ja nicht solche Laufzeitprobleme, wenn der Schreib-/Lesekopf ständig umpositioniert werden muß. :stupid:
Gute SSDs unterstützen manchmal sogar einen paralellen Zugriff, womit Multithread dann doch Vorteile bringen könnte, aber wieviele SSDs gibt's denn ... im Durchschnitt also mehr Nachteil,
es sei denn man baut beide Varianten ein, was auch nichts bringt, da sich SSDs aktuell noch nicht sicher erkennen lassen.

[relocate]

Das kann man dann unter der Rubrik Erfahrung ablegen.

Das kann ich mir vorstellen, das liegt wirklich in keinem Verhältnis. Wenn der Assemblercode sehr komplex ist, ist es halt schwierig abzuschätzen wie weit die Optimierung klappen würde. Unter DOS war es ja Volkssport jedes Quentchen Zeit aus dem System zu holen, da es ja insgesamt alles sehr langsam war. Aber irgendwann war halt Schluss.

Hm, ja, da kann man das System sehr schnell ausbremsen, so viel zum Thema Verwendungszweck. Wenn man da nicht weiß, wie die Hardware funktioniert dann hilft auch nichts mehr. Ist die Frage ob es soviel Geschwindigkeitszuwachs gibt, wenn der nächste Zugriff ebenfalls schnell geht. Dann kann man sich den Multithreadaufwand sicher sparen.

So langsam wird der Thread zum Optimierungsthema.

[himitsu]

Zitat:

Zitat von relocate (Beitrag 1163442)

Unter DOS war es ja Volkssport jedes Quentchen Zeit aus dem System zu holen

Das gibt es heite auch noch. Ob nun Linux, Windows oder Sonstewas, das ist hierbei egal.

Das fängt mit NonVCL an.
(siehe die Beiträge im Forum und unzähligen Beispiele auf Luckies Webseite www.michael-puff.de )
Dort verzichtet man auf große vorgefertigte Bibliotheken (vorallem die VCL) und macht nahezu alles selber.

Oder schau dir Mal die Demoszene an, die machen vielleicht kranke Sachen.
Man versucht möglichst viel in möglichst wenig reinzubekommen.
z.B. kkrieger ( www.youtube.com/watch?v=oKCFq5GsrV0 )


www.theproduct.de
www.farb-rausch.de
www.pouet.net/prod.php?which=25889
http://en.wikipedia.org/wiki/64k_intro
http://en.wikipedia.org/wiki/Farbrausch (gibt's sogar in deutsch)
http://www.delphipraxis.net/132115-d...mme-~-1kb.html
...

[relocate]

Klar gibt es das heute noch, aber früher war es ja fast schon zwingend.
(DOS Speichergrenze, PCs im MHz Bereich statt GHz-Wahnsinn, manchmal habe ich das Gefühl die PCs von heute sind da nicht schneller, ich weiß, heute passiert auch viel mehr auf den Maschinen unter Windows, aber viele Programme sind rausgeschleudert, nach dem Motto Hauptsache geht, wie ist egal.)

Natürlich war da auch die Demoszene Vorreiter.

NonVCL entwickle ich zum Teil auch. Bin aus der Admin-Schiene und um meine Arbeit zu erleichtern schreibe ich mir das ein oder andere Tool.
Damit es schneller geht oft erst VCL aber die Größe der EXE Dateien schreckt mich oft ab und dann fange ich an zu optimieren, wenn das Tool öfter zum Einsatz kommt.

KKrieger kenne ich, das Ding hat mein Laptop auf dem Gewissen.
(Nein, nicht wirklich, aber beim Abspielen ist er fast den Hitzetod gestorben).

Farbrausch kenne ich daher auch.

Das kannte ich noch nicht. Dass es da noch mehr Reserven gibt mit dem Austausch der System Unit, cool.

Nochmals, vielen Dank.