String in TStringList finden verschnellern?

[EmWieMichael]

Zitat:

Zitat von himitsu (Beitrag 1358343)

...
65 bis 128 = maximal 7 Vergleiche
129 bis 256 Werte = maximal 8 Vergleiche
257 bis 512 Werte = maximal 9 Vergleiche
513 bis 1024 Werte = maximal 10 Vergleiche
...

Täusche ich mich, oder werden bei dieser Rechnung die Vergleiche mit '=' vergessen? Ich muss doch nach jeder Halbierung zwei Vergleiche anstellen: '=' und ('<' oder '>').
Oder ist es mit 8 Uhr noch zu früh für mich...? :oops:

[a.def]

Zitat:

Zitat von haentschman (Beitrag 1358369)

Moin...8-)

Was ich nicht verstehe, das du dich gegen das angesprochene TDictionary, jedenfalls habe ich es nicht gesehen, wehrst... :gruebel: Das ist genau das für den Einsatzzweck gut ist... als das rumgeeiere mit der Stringlist... :roll:

Ich wehre mich doch nicht dagegen :P
Ich kenne es nur nicht.

Ist das in etwas so? http://www.delphipraxis.net/94559-ei...onary-map.html
Wenn ja, dann bedeutet das ja "doppelte Buchführung" wenn ich das richtig sehe. Denn man braucht einen linken und rechten Teil um ein Paar zu bilden.

[himitsu]

Zitat:

Zitat von EmWieMichael (Beitrag 1358370)

Täusche ich mich, oder werden bei dieser Rechnung die Vergleiche mit '=' vergessen? Ich muss doch nach jeder Halbierung zwei Vergleiche anstellen: '=' und ('<' oder '>').

Rein "logisch" nur eine mathematische Rechnung.

Delphi-Quellcode:

V = A - B

(gleich 0, kleiner 0, größer 0)
CompareValue
Dann weiß man sofort ob größer, kleiner oder gleich.

Aber aus diesem Grund sind Hash-Listen schneller, da dort je Wert nur ein "Vergleich" nötig ist, während bei Strings ja jedes einzelne Char verglichen werden muß.

Die genaue Anzahl der physischen Vergleiche, im Bytecode (Assembler) oder gar in der CPU, will man besser nicht wissen.
Für einen Vergleich zweier Suchalgorithmen reicht es, wenn man die ungefähre Anzahl der logischen Vergleichsoperationen kennt.

[a.def]

Bei einem ganz einfachen Test war bei mir die normale StringList schneller

Delphi-Quellcode:

procedure TForm1.Button2Click(Sender: TObject);
var
 sl: THashedStringList;
 i, X: Integer;
 Watch: TStopwatch;
begin
 sl := THashedStringList.Create;

 sl.Sorted := True;
 for i := 0 to 49999 do
  sl.Add(TStringUtils.RandomString(60));

 sl.Add('ABCABCABC');

 for i := 0 to 49999 do
  sl.Add(TStringUtils.RandomString(60));

 Watch := TStopwatch.Create;
 Watch.Start;

 for i := 0 to sl.Count - 1 do
  begin
   sl.Find('ABCABCABC', X); // Absichtlich kein Break, damit alles verglichen wird
  end;

 Watch.Stop;
 ShowMessage(IntToStr(Watch.ElapsedMilliseconds) + 'ms');
 sl.Free;
end;

// StringList: ~180ms
// HashedList: ~200ms

[himitsu]

Das liegt daran, dass du ausgerechnet die grausamste und sinnloseste Implementation einer Hashlist erwischt hast.

Delphi-Quellcode:

//Unit IniFiles

function THashedStringList.IndexOf(const S: string): Integer;
begin
  UpdateValueHash;
  if not CaseSensitive then
    Result := FValueHash.ValueOf(AnsiUpperCase(S))
  else
    Result := FValueHash.ValueOf(S);
end;

Vor jeder einzelnen Suchanfrage werden ALLE Hashs neu berechnet. :wall:
Das muß zwangsläufig langsamer sein.

[a.def]

Zitat:

Zitat von himitsu (Beitrag 1358380)

Vor jeder einzelnen Suchanfrage werden ALLE Hashs neu berechnet. :wall:

Wenn die HashedStringList mit diesem groben, sagen wir mal, "Fehler" diese geschwindigkeit erzielt (nur 20ms langsamer als die normale in meinem Beispiel), dann muss die ja super schnell sein, wenn dieser "Fehler" nicht ist.

Ich habe das jetzt mal mit IndexOf statt Find gemacht und da ist die HashedStringList schneller als die normale (trotz Neuberechnung der Hashes)

[haentschman]

Zitat:

Ist das in etwas so?

Nöö... :P

Schau mal hier: http://docwiki.embarcadero.com/Libra...ns.TDictionary

eine der Varianten...TryGetValue: http://docwiki.embarcadero.com/Libra...ry.TryGetValue
... gibt den Value zurück wenn Key gefunden wird.

[nahpets]

Wenn man in IndexOf und Find reinschaut, sieht man, dass da noch ziemlich vieles gemacht wird, um zum Vergleichsergebnis zu kommen.

Hier wird aber doch "nur" ein einfacher Vergleich auf Übereinstimmung von Zeichenfolgen in 'ner sortierten Stringliste benötigt.

Wie wäre es denn, hier einfach mal 'ne eigene Suchroutine zu schreiben, der die Stringliste übergeben wird und die als Rückgabewert den Index des gesuchten Eintrages der Stringliste liefert.

Ungetestet und nur hingedaddelt, daher ohne jegliche Garantie für irgendwas, sondern nur als Idee für's eigene Ausprobieren:

Delphi-Quellcode:

function BinSearch(Suche : String; Start : Integer; Ende : Integer; sl : TStringList) : Integer;
var
        Mitte : Integer;
begin
  Mitte := Start + ((Ende - Start) div 2);
  if Suche <= sl[Mitte] then Result := BinSearch(Suche, Start, Mitte, sl)
  else Result := BinSearch(Suche, Mitte, Ende, sl);
end;

Hier fehlt zum Beispiel noch die Prüfung, ob der Suchbegriff überhaupt in der Stringliste vorkommt, also ist

Delphi-Quellcode:

sl[BinSearch('ASDF',0,sl.Count - 1,sl) = 'ASDF';

Könnte daraus eventuell dann sowas werden?

Delphi-Quellcode:

function IndexOfListObjects(const sTmp: string; List: TStringList): Integer;
begin
 Result := BinSearch(sTmp,0,List.Count - 1,List);
 if List[Result] <> sTmp then Result := -1;
end;

[p80286]

Zitat:

Zitat von himitsu (Beitrag 1358378)

Aber aus diesem Grund sind Hash-Listen schneller, da dort je Wert nur ein "Vergleich" nötig ist, während bei Strings ja jedes einzelne Char verglichen werden muß.

Naja nicht unbedingt, "damals" haben wir die Strings in 16-Bit Werte zerhackt, und diese dann verglichen, da konnte man gegenüber den 8-Bit Vergleichen knappe 50% herausholen. Mit 32-Bit oder gar 64-Bit kann man da gut Gas geben. Und die hash-Berechnung fällt nicht an.

Gruß
K-H

[Uwe Raabe]

Zitat:

Zitat von nahpets (Beitrag 1358385)

Wenn man in IndexOf und Find reinschaut, sieht man, dass da noch ziemlich vieles gemacht wird, um zum Vergleichsergebnis zu kommen.

Insbesondere sieht man, daß

Delphi-Quellcode:

Find

eine binäre Suche durchführt und

Delphi-Quellcode:

IndexOf

direkt Find aufruft, wenn

Delphi-Quellcode:

Sorted

gesetzt ist.

Daraus folgt a) daß

Delphi-Quellcode:

Find

nur dann funktionieren kann, wenn

Delphi-Quellcode:

Sorted

gesetzt wurde, und b)

Delphi-Quellcode:

IndexOf

immer funktioniert c)

Delphi-Quellcode:

IndexOf

im Falle von

Delphi-Quellcode:

Sorted

wegen der binären Suche in

Delphi-Quellcode:

Find

schon recht schnell sein sollte.

Bleiben noch die Optimierungsmöglichkeiten in

Delphi-Quellcode:

CompareStrings

, das sowohl von

Delphi-Quellcode:

Find

als auch von

Delphi-Quellcode:

IndexOf

im Falle von

Delphi-Quellcode:

Sorted = false

aufgerufen wird. Da CompareStrings virtuell ist müssen wir hier die Implementierung in TStringList heranziehen. Darin wird je nach Kombination der Properties UseLocale und CaseSensitive CompareStr oder CompareText bzw. der Ansi-Pendants aufgerufen. Letztere bemühen jeweils eine Funktion aus der Windows-API und sind somit potentiell langsamer als ihre nativen Vettern. Diese beiden (CompareStr und CompareText) sind aus dem Fastcode-Projekt übernommen worden und somit potentiell auch nicht die langsamsten. Da die Text-Variante noch die Groß/Klein-Schreibung berücksichtigt (in dem sie sie ignoriert), ist diese potentiell noch etwas langsamer als CompareStr, daß einen direkten Vergleich durchführt.

Folglich sollte das beste Ergebnis erzielt werden, wenn die Stringlist mit folgenden Einstellungen betrieben wird:

Delphi-Quellcode:

Sorted := true;
CaseSensitive := true;
UseLocale := false;

Trotzdem kann das stumpfe Iterieren durch alle Strings mit einem direkten Vergleich durchaus deutlich schneller sein, als das Find. Im Gegensatz zu CompareString, daß einen Ordnungsvergleich (kleiner, gleich, größer) durchführt, wird bei einem direkten Vergleich eben nur auf Gleichheit getestet. Da Strings aber referenzgezählte Objekte sind, kann bei diesem Vergleich als erstes geprüft werden, ob es sich um dasselbe Objekt handelt und nicht nur um einen String mit demselben Inhalt.

Selbst bei mehreren Millionen Einträgen kann der Brute-Force Ansatz immer noch schneller sein. Man sollte das also mit realen Daten testen, bevor man blind eine bestimmte Methode einsetzt.