NonVCL Version von Classes.dcu

[scp]

Folgender Erweiterungsvorschlag für TStrList:

1. Die Funktion Strings in GetStr und Replace in SetStr umbenennen.
2. Die beiden Functionen in den protected Bereich verschieben.
3. Folgende Zeile ans Ende der public-Deklarition einfügen:

    property Strings[Index : Integer] : String read GetStr write SetStr; default; Somit hat man mit ein bißchen Code ein Stück mehr das Verhalten von TStringList / TStrings.

[OLLI_T]

Da sind aber viele Fehler drin in dieser Klasse TStrList ...

[scp]

Zitat von OLLI_T:

Da sind aber viele Fehler drin in dieser Klasse TStrList ...

Na, dann leg mal los. Ich hab sonst nix aussergewöhnliches gesehen. "Viele Fehler" ist ja nicht gerade eine hilfreiche Aussage.

[Luckie]

Zitat von scp:

Zitat von OLLI_T:

Da sind aber viele Fehler drin in dieser Klasse TStrList ...

Na, dann leg mal los. Ich hab sonst nix aussergewöhnliches gesehen. "Viele Fehler" ist ja nicht gerade eine hilfreiche Aussage.

Und bitte besser machen.

[jbg]

Zitat von Luckie:

Jedes mal, wenn du was hinzufügst (Methode Add) verlängerst du das Array um eins und fügst den String dort ein.

Na dann viel Spaß mit dem sagenhaft geringen Speicherverbrauch von 200 MB für 5000 Elemente vom Typ Integer.

[Luckie]

War ja auch nur die einfache Version. Dass dies Speichertechnisch eigentlich Selbstmord ist, hätte ich noch erwähnen sollen. Aber in der hier geposteten Unit wird es nicht anders gemacht.

[scp]

Zitat von jbg:

Zitat von Luckie:

Jedes mal, wenn du was hinzufügst (Methode Add) verlängerst du das Array um eins und fügst den String dort ein.

Na dann viel Spaß mit dem sagenhaft geringen Speicherverbrauch von 200 MB für 5000 Elemente vom Typ Integer.

Ich weis zwar jetzt nich genau worauf du hinaus willst, aber die hier dargestellte TStrList unterscheidet sich kaum vom Original.
Auch bei der Borlandschen Version wird ein array verwendet, nur ist dies halt eine andere Art dynamisches Array:

Delphi-Quellcode:

  PStringItemList = ^TStringItemList;
  TStringItemList = array[0..MaxListSize] of TStringItem;

Es ist also zunächst eine statische Array, die aber nur den gerade nötigen Teil für die Anzahl Items per ReAllocMem() zugewiesen bekommt. Dies benötigt aber ebenfalls pro Element einen Integer-Wert (eigentlich ja Pointer), also 4 Byte + die Stringdaten.

PS: 5000 * 4 Byte sind doch 20000 Byte ~ 19,5 KB, oder wie meinst du das?

[Chewie]

Bei jedem Aufruf von SetLength wird das ganze Array an eine andere Speicherstelle verschoben, da nicht sicher ist, ob hinter der aktuellen Stelle noch genügend Platz dafür ist.
Durch irgendeine Schwäche im Delphi-Speichermanager (genaueres weiß ich auch nicht, würde mich auch mal interessieren) kann es nun passieren (und es passiert), dass der Speicher, den das Array vor dem Verschieben belegte, nicht wieder frei gegeben wird. Dadurch kommt die hohe Speicherbelastung zu Stande.
Daneben ist es natürlich auch höchst in effizient, wenn ständig Massen von Daten rumgeschoben werden, nur weil ein neuer String dazukommz.

[jbg]

Zitat von scp:

aber die hier dargestellte TStrList unterscheidet sich kaum vom Original.

Aber das bisschen ist schon sehr ausschlaggebend.

Zitat:

Auch bei der Borlandschen Version wird ein array verwendet, nur ist dies halt eine andere Art dynamisches Array:

Das ist nicht das Problem.

Zitat:

5000 * 4 Byte sind doch 20000 Byte ~ 19,5 KB, oder wie meinst du das?

Theoretisch werden die 20000 Bytes auch nur reserviert. Praktisch wird Windows aber der Speicher in nicht geringen Mengen entzugen.

Zitat:

Es ist also zunächst eine statische Array, die aber nur den gerade nötigen Teil für die Anzahl Items per ReAllocMem() zugewiesen bekommt. Dies benötigt aber ebenfalls pro Element einen Integer-Wert (eigentlich ja Pointer), also 4 Byte + die Stringdaten.

Um es mal übertrieben darzustellen: Mit dieser Technik mishandelst du den Speichermanager von Delphi, der es dir dann mit einem Speicherbedraf gegen unendlich heimzahlt.

Bei jedem SetLength(a, Length(a) + 1) wird ein neuer Speicherbereich reserviert, die Daten kopiert und der alte als "Frei" vermerkt, also nicht an Windows zurückgegeben, da er später wieder benutzt werden könnte und somit schneller bereit steht, als wenn er erst bei Windows angefordert werden muss. Kommt nun die nächste Vergrößerung, so muss der Speichermanager wieder einen neuen Speicherbereich bei Windows reservieren, da das nun größere Array nicht in einen zuvor reservierten Speicher passt ...

Darum ist es besser, wenn man das Array einmalig auf die End-Länge setzt, anstatt jedesmal eins zur Länge hinzuzuaddieren. Man spart sich auch das ständige Kopieren des Arrays und gewinnt neben Speicherplatz auch an Geschwindigkeit.

Delphi-Quellcode:

var
  i: Integer;
  a: array of Integer;
begin
  ShowMessage('Start - Speicherschlucken');
  a := nil;
  for i := 0 to 99999 do
  begin
    SetLength(a, Length(a) + 1);
    a[i] := i;
  end;
  ShowMessage('Ende');
end;

Delphi-Quellcode:

var
  i: Integer;
  a: array of Integer;
begin
  ShowMessage('Start - Schneller und Speicherschonend');
  SetLength(a, 100000);
  for i := 0 to 99999 do
    a[i] := i;
  ShowMessage('Ende');
end;

[scp]

@chewie
Ersteres kann ich ja verstehen, wenn dem so ist, ist das natürlich ineffizient.

Aber das Massen von Daten verschoben werden, finde ich nicht so schlimm, es sind hier ja bei dem Bespiel mit den 5000 Elementen nur die 20 KB, was ja heutzutage nicht viel ist, die Daten der Strings bleiben ja unangetastet, weil es ja für jeden String einen Extra-Pointer/-Referenzzähler gibt.