NonVCL Version von Classes.dcu

[scp]

Zitat von jbg:

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.

Das war ja nicht meine Idee, sondern Borlands, die werden wohl ihren Speichermanager kennen?!?
Schau einfach mal in der Classes.pas, hast ja die D6Pro.

[jbg]

Zitat von Chewie:

Durch irgendeine Schwäche im Delphi-Speichermanager

Das ist mehr eine Stärke des Delphi-Speichermanagers, die sich nur bei falscher Verwendung eben stark ins negative wendet.

Zitat:

kann es nun passieren (und es passiert), dass der Speicher, den das Array vor dem Verschieben belegte, nicht wieder frei gegeben wird.

Der Speicher wird schon freigegeben. Wobei er aber nicht an Windows-Speichermanager, sondern an den Delphi-Speichermanager geht, der sich die Adresse merkt um neue Anforderungen viel schneller zu verarbeiten als es der Windows Speichermanager kann.


Du kannst den folgenden Speichermanager, der nichts anderes macht als den Windows-Speichermanager aufzurufen, ja mal als Ersatz nehmen. (Erste Unit im Projektquellcode). Der Geschwindigkeitsunterschied bei vielen Komponenten auf den Formularen ist spürbar.

Delphi-Quellcode:

unit WinMemMan;
interface
uses Windows;

implementation
const
  HEAP_NO_SERIALIZE = 1;
  HEAP_ZERO_MEMORY  = 8;

  HeapFlags: array[False..True] of Cardinal = (HEAP_NO_SERIALIZE, 0);

var
  ProcessHeap: THandle;

function HeapGetMem(Size: Integer): Pointer;
begin
  Result := HeapAlloc(ProcessHeap, HeapFlags[IsMultiThread], Size);
end;

function HeapFreeMem(P: Pointer): Integer;
begin
  if HeapFree(ProcessHeap, HeapFlags[IsMultiThread], P) then Result := 0 else Result := 1;
end;

function HeapReallocMem(P: Pointer; Size: Integer): Pointer;
begin
  Result := HeapReAlloc(ProcessHeap, HeapFlags[IsMultiThread], P, Cardinal(Size));
end;

procedure InitializeHeapMemManager;
var HeapMemManager: TMemoryManager;
begin
  ProcessHeap := GetProcessHeap;
  HeapMemManager.GetMem := HeapGetMem;
  HeapMemManager.FreeMem := HeapFreeMem;
  HeapMemManager.ReallocMem := HeapReallocMem;
  SetMemoryManager(HeapMemManager);
end;

initialization
  InitializeHeapMemManager;

end.

[jbg]

[quote="scp"]

Zitat von jbg:

Das war ja nicht meine Idee, sondern Borlands, die werden wohl ihren Speichermanager kennen?!?

Genau. Borland kennen ihren Speichermanager und haben die Mishandlung auch umgangen.

Zitat:

Schau einfach mal in der Classes.pas, hast ja die D6Pro.

Das solltest du auch tun. Vielleicht fällt dir dann die Eigenschaft Capacity auf.

[scp]

Stimmt, die kenn ich zwar, hatte sie aber jetzt völlig ausser acht gelassen. Na dann eine andere Theorie:
Ist es nicht möglich, das bei einem dynamischen Array intern die gleiche vorgehensweise wie bei TStringList verwendet wird?

[jbg]

Natürlich. Schau dir einfach mal an, wie Borland das bei TStringList/TList mit Capacity gelöst hat. Einfach mal die gesamte Classes.pas nach Capacity durchsuchen. Dort wirst du auch eine schöne Formel finden, die sehr effektiv ist.

Da TStringList/TList noch aus Delphi 1 Zeiten stammen, wo dynamischen Arrays noch nicht vom Compiler unterstützt wurden, hat Borland einfach die "alte Art" der dynamischen Arrays benutzt.

[scp]

Ich selbst nutze sowieso mittlerweile die "alte Variante", da ich die Quelltexte auch auf D3 laufen haben will. Schliesslich kann sich das jetzt jeder leisten.
Aber interessant mal die doch gravierenden Unterschiede kennenzulernen.