Stringkonkatenation ist schneller als direktes Kopieren?

[Meflin]

Zitat:

Zitat von alzaimar

Noch lustiger: Ich ersetze also TStringList mit einem dynamischen Stringarray... Lasst Euch überraschen

Womit meine Ergebnisse aus dem anderen Thread ja bestätigt wären :stupid:

Freut mich, dass meine Frage zu einer so regen Diskussion geführt hat :mrgreen: Ich hoffe es kommt auch noch was schnelles dabei raus :zwinker:

[jbg]

Zitat:

Zitat von Meflin

Ich hoffe es kommt auch noch was schnelles dabei raus

Klar geht es noch schneller. Nur wird es dann ziemlich lowlevelig und spezialisierter.

Delphi-Quellcode:

type
  THackedStringList = class(TStrings) // funktioniert nur noch mit echten TStringList Klassen
  public
    FList: PStringItemList;
  end;

function V2(s: TStringList): Integer;
var
  l, i, j, n: Integer;
  z: PChar;
  x: String;
  Arr: array of record
    Data: PChar;
    Len: Integer;
  end;
begin
  n := 0;
  SetLength(Arr, s.Count);
  for i := 0 To s.Count - 1 Do
  begin
    Arr[i].Data := Pointer(THackedStringList(s).FList[i].FString); // kein CPU LOCK mehr
    Arr[i].Len := Length(PString(@Arr[i].Data)^);
    Inc(n, Arr[i].Len);
  end;

  SetLength(x, n);
  j := 0; // PChar startet bei 0
  for i := 0 To High(Arr) do
  begin
    z := Arr[i].Data;
    l := Arr[i].Len;
    Move(z^, PChar(PChar(Pointer(x)) + j)^, l * SizeOf(Char)); // kein UniqueString aufrufen
    Inc(j, l);
  end;

  Result := Length(x);
end;

[alzaimar]

@jbg: Wir argumentieren doch immer so, das bei einer Stringkonkatenation (hier) 1 Mio mal neuer Speicher angefordert und der String umkopiert werden muss, und das dauert und daher sollte man V2 nehmen. Wir alle predigen das, und das basiert ja i.A. auf eigenen Erfahrungen.

Wenn man das dann mal manifestieren will (sozusagen als Demo fur Dummies), fällt man so richtig (aber so richtig!) auf die Plautze.

Ehrlich gesagt bin ich etwas verwirrt.

[jbg]

Zitat:

Zitat von alzaimar

@jbg: Wir argumentieren doch immer so, das bei einer Stringkonkatenation (hier) 1 Mio mal neuer Speicher angefordert und der String umkopiert werden muss, und das dauert und daher sollte man V2 nehmen.

Das ist auch so richtig. Nur gehen wir dabei nicht mehr mit der Zeit. Wenn FastMM4 im Spiel ist, werden String-Konkatenationen schon mal von Haus aus schneller, weil nicht mehr für jedes zusätzliche Zeichen neuer Speicher angefordert wird, sondern immer in größeren Blöcken. Das wird dann zwar mit mehr Speicherverbrauch bezahlt, aber bei den heutigen RAM Größen ist das vernachlässigbar.
Zum anderen kommen bei heutigen Systemen mehrere CPUs ins Spiel. Dort sind die CPU LOCKs (derer gleich drei Stück in LStrAsg enthalten sind) teurer, weil ja tatsächlich eine andere CPU auf den Speicher zugreifen könnte. Davon sind Hyperthreading Prozessoren ebenfalls betroffen.

Zitat:

Wenn man das dann mal manifestieren will (sozusagen als Demo fur Dummies), fällt man so richtig (aber so richtig!) auf die Plautze.

Compilermagic kann eben grausam sein. :mrgreen:

Zitat:

Ehrlich gesagt bin ich etwas verwirrt.

Das bin ich zwar nicht, aber um das ganze Schneller zu machen, muss nun der ohnehin schon kompliziertere Code nochmals verkompliziert werden. Am Schluss blickt man dann gar nicht mehr durch, weil es nur noch so von "Compiler lass die verdammte Compilermagic hier weg" Anweisungen so wimmelt.

[alzaimar]

Bei mir ist selbst bei FastMM4 die Konkatenation schneller.

Ich schließe daraus, das wir uns nicht mehr so sehr um Performance scheren müssen, sondern eher die Verfahren optimieren können. Delphi und moderne MMS kompilieren das schon recht ordendlich. Ich persönlich finde das beruhigend, weil ich -ehrlich gesagt- nicht ständig mit irgendwelchen Tricks rumhantieren muss, sondern mich auf Algorithmen und Verfahren konzentrieren kann.

Danke für die Analysen.