[Optimiert] Explode Prozedur - Reloaded (Ersatz für CodeLib)

[alzaimar]

Hi!
Ich hab mir mal die Mühe gemacht, und eine alternative Explode-Funktion implementiert, die wohl doch etwas schneller ist, als die hier in der Code-Library hinterlegte Version.

Ich möchte Euch bitten, den Code zu testen und auch zu optimieren. Wenn wir damit durch sind, sollte diese Version in die Code-Library übernommen werden, bzw die jetzige Version ersetzen.

Details über die Herleitung (na ja, Recherche und Kopieren ) steht im Code.

[Edit] Unten genannte Tests sowie Zeitmessung eingearbeitet: Es ist ein komplettes Projekt mit Funktions- und Speed-Test. Bitte versucht, Teile davon zu optimieren (ASM, Pointer arithmetic etc.). [/edit]

History:
12.12. Version 1.1: Erste schwere Fehler ausgebaut: Strings am Ende wurden falsch bzw. gar nicht erkannt.
13.12. Version 1.2: Kleiner Fehler in der Prepare-Methode: (Hilfsvariable als Cardinal deklariert, bei Zuweisung <0 ignoriert), Facelifting auf Anregung von Elvis (Feld- und Variablennomenklatur). Ferner ist eine Test-Iterator-Basisklasse sowie ein Iterator für Char-Delimiter (z.B. für CSV) implementiert.
14.12 Version 1.3: Iterator für QS-Search implementier. Die Test-Routine wurde um Zeitmessungen für den Iterator sowie die Code-Library ergänzt.
23.12.07 Version 1.4: Beseitigt seltenen Bereichsüberlauf am Ende eines Strings.

Diese Version ist zwischen 4 und 1000x schneller als die Version aus der Code-Library.

[stoxx]

Zitat von alzaimar:

Zitat von stoxx:

also mit der Lösung im Anhang bin ich auf 93,1 MB pro Sekunden.

Aber du liest die Strings nicht aus, oder? Du rufst doch nur 'explode' auf, gell?

doch, doch, die werden schon ausgelesen, nämlich einem String zugewiesen.
Soviel bräuchte man, wenn man daraus irgendwas machen will (Zahlen umwandeln oder sonstwas)

Das wäre ein einziger Zugriff auf den Original String, da ich diesen mir auch nicht als Member Variable speicher.
(Copy on Write) sobald man da irgendwas verändert.

für ein oder zwei Zeichen hätte ich noch eine Idee für Dich, wenn Du wirklich unbedingt alles in TStrings haben willst.

Du nimmst einfach den Original String, setzt einen Pointer drauf, und ersetzt das Trennzeichen durch eine #10
oder#13.

Dann wirfst Du den gesamten String mit einem Rutsch mit TStrings.text drauf.
Danach machst Du Deine Änderungen wieder rückgängig, und ersetzt Deine selber gesetzten #10 wieder
Oder wenn es auch mit einem Substring länger als 2 Zeichen funktionieren soll, kööönte man sich ja auch mal in der Unit Classes die
Methode: procedure TStrings.SetTextStr(const Value: string); ansehen und ein wenig umstrukturieren.


So hättest Du es auch in TStrings, und wahrscheinlich genauso schnell

Zitat:

Ich finde, mit den 50% kann man in den meisten Fällen leben (Man spart z.B. bei 1.000.000 Lese- und Schreibzugriffen ca. 250ms ein... Na ja.)

ja, wenn es einmal da ist, aber um mit Strings zu operieren, um sie weiter zu verarbeiten , naaaaja
Da bracht es wesentlich länger, da TStrings ja mit SetString sich eine Kopie vom OriginalString holt ...

[stoxx]

ups, dopptelt (gelöscht)

[stoxx]

Zitat von alzaimar:

Zitat von stoxx:

also mit der Lösung im Anhang bin ich auf 93,1 MB pro Sekunden.

Aber du liest die Strings nicht aus, oder? Du rufst doch nur 'explode' auf, gell?

das ist MIT auslesen, ohne auslesen und nur explode kommt man auf 215 MB/s
Und wenn man nur einen string braucht vielleicht nur auf 210 MB/s? .. hihi .. keine Ahung.
kann man testen ...


ohne auslesen, nur explode:

Using TStringExploder in TStringList
100 chars per line; Itemlänge: 10; 1000000 lines in 453 tics, 2207506 lines per sec, 215,6 mb/s (del = ";")
10000 chars per line; Itemlänge: 100; 50000 lines in 1375 tics, 36364 lines per sec, 355,1 mb/s (del = ";")
1000000 chars per line; Itemlänge: 1000; 500 lines in 1344 tics, 372 lines per sec, 363,3 mb/s (del = ";")
100 chars per line; Itemlänge: 5; 1000000 lines in 422 tics, 2369668 lines per sec, 231,4 mb/s (del = ";")
1000 chars per line; Itemlänge: 5; 500000 lines in 1937 tics, 258131 lines per sec, 252,1 mb/s (del = ";")

[alzaimar]

Zitat von stoxx:

Zitat von alzaimar:

Zitat von stoxx:

also mit der Lösung im Anhang bin ich auf 93,1 MB pro Sekunden.

Aber du liest die Strings nicht aus, oder? Du rufst doch nur 'explode' auf, gell?

doch, doch, die werden schon ausgelesen, nämlich einem String zugewiesen.

Goil

[stoxx]

Zitat:

Unten genannte Tests sowie Zeitmessung eingearbeitet: Es ist ein komplettes Projekt mit Funktions- und Speed-Test. Bitte versucht, Teile davon zu optimieren (ASM, Pointer arithmetic etc.).

isch hab noch bissi dran rumgeschraubt *g*
zumindest für einen Seperator mit der Zeichenlänge eins
bist Du noch schneller mit asm + strings, als mit einer optimierten Pointerlösung ? .. würde mich jetzt mal interessieren


Hier der Vergleich auf einem "alten" 3200+ AMD als Referenz ...

-------------------------------------------------
Compiliertes Eingangsbeispiel von alzaimar
-------------------------------------------------
100 chars per line: 1000000 lines in 6469 tics, 154583 lines per sec, 15,1 mb/s (del = ";")
10000 chars per line: 50000 lines in 9594 tics, 5212 lines per sec, 50,9 mb/s (del = ";")
1000000 chars per line: 500 lines in 3953 tics, 126 lines per sec, 123,5 mb/s (del = ";")


------------------------------------------------
mit Delphi 2007 compiliert ( Codegear hat ein paar Lösungen vom Fastcode Projekt intern integriert)
-------------------------------------------------
Using TStringDivider in TStringList
100 chars per line: 1000000 lines in 3844 tics, 260146 lines per sec, 25,4 mb/s (del = ";")
10000 chars per line: 50000 lines in 4375 tics, 11429 lines per sec, 111,6 mb/s (del = ";")
1000000 chars per line: 500 lines in 3641 tics, 137 lines per sec, 134,1 mb/s (del = ";")


-------------------------------------------------
TFastStringExploder .....
-------------------------------------------------
Using TStringExploder in TStringList
100 chars per line; Itemlänge: 10; 1000000 lines in 937 tics, 1067236 lines per sec, 104,2 mb/s (del = ";")
10000 chars per line; Itemlänge: 100; 50000 lines in 1234 tics, 40519 lines per sec, 395,7 mb/s (del = ";")
1000000 chars per line; Itemlänge: 1000; 500 lines in 968 tics, 517 lines per sec, 504,4 mb/s (del = ";")

[toms]

TFastStringExploder ist leider nicht D6/D7/.. kompatibel, da private Felder im Record verwendet werden.

Musst für einen Test unter D6 TFastStringExploder = Class ändern und das static entfernen.
Nachtrag: War keine gute Idee, gib dann eine AV.

[alzaimar]

Du must nur einen Konstruktor/Destruktor einbauen, der die Felder initialisiert. Weiterhin ist da ein Bug beim Vergrößern des FPointer-Arrays...

Hier eine Version, die bei mir funktioniert.

[stoxx]

Zitat von alzaimar:

Hier eine Version, die bei mir funktioniert.

ja, da war ein Bug im Array vergrößern drin, die version die Du hochgeladen hast, war nicht die letzte und schnellste
Ist auch noch ein kleiner Bug drin ( in der letzten) .. muss ich aber nochmal drüber nachdenken.
ich ersetzte ja die Null nach einem String mit dem FSeperator .. die müsste man wieder herstellen.
Delphi selber geht in seinen TSTrings Routinen auch davon aus, dass die Null garantiert da ist, nach einem String, ich denke, man kann sich darauf also auch verlassen.
Oder man würde nur das letzte Zeichen des Strings ersetzen, und wieder herstellen ...

[stoxx]

Zitat von toms:

Nachtrag: War keine gute Idee, gib dann eine AV.

die gab es nur, weil Du wahrscheinlich mit einem Resourcestring getestet hast
das geht nicht so wirklich ....
nur normale Strings ...

also NICHT:

Delphi-Quellcode:

var s : String;
begin
    s := 'ghh,dddd';
    Exploder.explode(s);

end;

sondern:

Delphi-Quellcode:

var s : String;
begin
    
    s := 'ghh,dddd,'; 
    s := s + 'AAA';
    Exploder.explode(s);

end;

bei einer Klasse oder umstellen des Codes müsste man aber erst wieder noch die Sprungadresse auf Startloop optimieren ... ( bringt ungefähr 10-20 Prozent bei mir) .. je nachdem wie schlecht sie ist

[C.Schoch]

Hi,
Ich hab eine kleine Erweiterung von alzaimars Version die mit einem Dynamischen Array arbeitet das bringt durch den verringerten Verwaltungsaufwand noch mal 5 - 50% Geschwindigkeit
Vielleicht kann diese Ergänzung gleich in zukünftige Versionen mit einfließen