Eine Frage der Performance - T(Object)List oder Dyn. Array?

[Mithrandir]

Sry, Doppelposting, aber:

Um das Problem zu isolieren, habe ich mal eine kleine Test-App geschrieben. Sie befindet sich im Anhang, das Listing im Posting. Ich bin jedenfalls noch nicht weitergekommen..

Der Aufbau entspricht in etwa dem in der "echten" Anwendung.

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, Unit2, csDictionary;

type
  TForm1 = class(TForm)
    Button1: TButton;
    Memo1: TMemo;
    Button2: TButton;
    procedure FormCreate(Sender: TObject);
    procedure FormClose(Sender: TObject; var Action: TCloseAction);
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
  private
    procedure AddItem(Node: TORPNode);
    function ReadItem(ID: Cardinal): TORPNode;
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;
  Dict: TIntegerDictionary;

implementation

{$R *.dfm}

function TForm1.ReadItem(ID: Cardinal): TORPNode;
var
  pter: Pointer;
begin
  Dict.Find(ID, pter);
  Result := TORPNode(pter^);
end;

procedure TForm1.AddItem(Node: TORPNode);
begin
  Dict.Add(Node.ID, Pointer(Node));
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  i: integer;
  fNode: TORPNode;
begin
  Button2.Enabled := false;
  for i := 0 to 1000 do
    begin
      fNode := TORPNode.Create;
      fNode.ID := i;
      fNode.Trst := Random(300000);
      AddItem(fNode);
    end;
  ShowMessage('Liste erstellt.');
  Button2.Enabled := true;
end;

procedure TForm1.Button2Click(Sender: TObject);
var
  i: Integer;
  fNode: TORPNode;
begin
  i := Random(1000);
  fNode := ReadItem(i);
  if fNode <> nil then
   begin
    Memo1.Lines.Add(IntToStr(fNode.ID));
    Memo1.Lines.Add('---------');
    Memo1.Lines.Add(IntToStr(fNode.Trst));
    Memo1.Lines.Add('');
   end
   else
    Memo1.Lines.Add('Misslungen...');
end;

procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
begin
  FreeAndNil(dict);
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  dict := TIntegerDictionary.Create;
  Button2.Enabled := false;
end;

end.


unit Unit2;

interface

Type
  TORPNode = class(TObject)
    ID : Cardinal;
    Trst: Integer;
  end;

implementation

end.

[Khabarakh]

Zitat von Daniel G:

Allerdings habe ich das irgendwie noch nicht ganz auf der Reihe.

Scheint so . Noch einmal: Eine Objektreferenz ist ein Pointer. Die Dereferenzierung beim Auslesen hat da nichts zu suchen. Abgesehen von dem Pointer-Cast und zurück musst du dich hier mit Pointern gar nicht auseinandersetzen.

[himitsu]

Im Notfall könnte man das Pferd auch von hinten aufzäumen

Hier ist einfach mal ganz schnell 'ne Version mit Objekten, anstatt Pointern:
(PS: wenn beim .Create der Parameter True ist, dann würden als "Bonus" die "eingelagerten" Objekte beim .Delete, bzw. beim .Destroy/.Free und .Clear vom Dictionary "automatisch" freigegeben)

[alzaimar]

Hi himitsu,
schöne kleine Verbesserung.

[Mithrandir]

Zitat von Khabarakh:

Zitat von Daniel G:

Allerdings habe ich das irgendwie noch nicht ganz auf der Reihe.

Scheint so . Noch einmal: Eine Objektreferenz ist ein Pointer. Die Dereferenzierung beim Auslesen hat da nichts zu suchen. Abgesehen von dem Pointer-Cast und zurück musst du dich hier mit Pointern gar nicht auseinandersetzen.

Hi Khabarakh,

das habe ich schon soweit verstanden. Allerdings scheiterte es an der simplen Umsetzung. Es war nicht das Wissen, was fehlte, sondern das Handwerkszeug. Ich hab mir das eben nochmal angesehen, und dann ist es mir wie Schuppen von den Augen gefallen. Einfach pter mit Result gleichsetzen. Schwuppdiewuppdi klappt das auch.


@Himi: Wird ab sofort eingesetzt.

[Mithrandir]

Zitat von Daniel G:

(Stand 11. Mai)
Knoten ~348 Mio.
Wege ~28 Mio.
Beziehungen 112357
*Für Deutschland rechne so überschlagsmäßig mit höchstens 1 - 2 Mio. Knoten...

Iiick muss da mal ne böse Fehlkalkulation gestehen. Ich habe eben mal den Import von Niedersachsen durchlaufen lassen. Am Ende des Programms lasse ich mir die Zahl der Knoten ausgeben:

Code:

---------------------------
saxxmltest
---------------------------
2294861
---------------------------
OK   
---------------------------

2,3 Mio. Knoten. Alleine in Niedersachsen. Somit kann man für ganz Deutschland vermutlich mit 15 - 20 Millionen Knoten rechnen... Heidewitzka... Die Verarbeitung einer 450 MB - Datei verbrauchte übrigens 350 MB Arbeitsspeicher... Ich denke, ich lasse morgen mal die Deutschlanddatei mit 4 GB importieren, um einen vernünftigen Überblick über die Dimensionen zu bekommen.

//Edit: Der Import dauerte übrigens 22 Minuten.

[Bbommel]

Hallo zusammen,

mir ist gerade beim Querlesen dieses Themas etwas aufgefallen, was zwar schon ein paar Tage her ist, aber worauf man vielleicht doch noch mal eingehen sollte - auch wenn es etwas von der ursprünglichen Frage von Daniel G weggeht. Es geht um eine Antwort von Hansa:

Zitat von Hansa:

Delphi-Quellcode:

TDaten = class (TObject)
  ID,
  nr  : integer;   
// weitere Nutzdaten
end;

TListe = class (TObjectList)
  Daten : TDaten;          // <--- Edit Bbommel: Das ist doch so nicht richtig, oder?
end;

var Liste : TListe;
    ListeElement : TDaten;

Die Liste weiß nun welche Daten sie erhalten soll.

Mir geht es um die von mir oben markierte Zeile und die damit wohl verbundene Aussage, dass die Liste nun weiß, welche Daten sie enthalten soll. Das halte ich so nicht für richtig. Man muss (und kann) doch einer Liste nicht anzeigen, welche Daten sie enthalten soll. Das muss sie ja auch gar nicht wissen, sondern nur, dass sie irgendwelche Nachfolger von TObject enthält, um deren Freigabe sie sich ggf. kümmern muss - alles weitere sollte die Liste selbst nicht interessieren.

In dem konkreten Beispiel von Hansa bräuchte man also eigentlich TObjectList gar nicht ableiten, sondern könnte es direkt benutzen, um die "TDaten" zu speichern. TObjectList braucht man nur dann abzuleiten, wenn man noch irgendwelche Eigenschaften für die Liste insgesamt speichern will, also sozusagen "Kopfdaten" für die gesamte Liste oder einen Status, solche Dinge. Gerne auch Methoden, mit denen die Objekte in der Liste irgendwie gespeichert und wieder geladen werden können.

@Hansa: Ich hoffe, das kommt jetzt nicht zu negativ rüber, aber es geht mir darum zu klären, ob ich selbst in den letzten Jahren etwas falsch verstanden habe, oder ob ich Glück habe und der Fehler lag wirklich bei dir. Oder ob ich deinen Beitrag irgendwie völlig falsch verstanden habe...

Bis denn
Bommel

[Hansa]

Tja, wer hat was falsch verstanden ? Du oder ich ? Befürchte Du. Warum ? Weil es erstmal fehlerfrei und wie gewünscht läuft, sonst hätte ich das auch nicht gepostet. Aber wer weiß, es könnte ja vielleicht doch so nicht ganz richtig sein ?

Nur geht es doch darum : irgendeine Liste muss da sein und sie muss konkrete Daten enthalten können. Die Liste ist mir dabei ziemlich egal, aber die Daten sollen schon so aussehen, wie ich sie brauche. Vielleicht ist das hier noch interessanter :

Delphi-Quellcode:

while not gefunden do begin
...
  ListeElement := (Liste.Items[i] as TDaten);
  gefunden := (ID = ListeElement.ID);

Ich suche etwas. Mit etwas Phantasie kann man erahnen, dass es bei der Liste darum geht, nicht unnötigerweise immer einunddieselben Datensätze neu lesen zu müssen. Beim Programmstart wird die aus DB gefüllt und dann wird nur noch diese Liste durchsucht, statt dauernd in der DB zu suchen (die Tabelle, um die es geht, ändert sich eigentlich nie). Wie soll ich aber nun die Liste nach gewisser ID durchsuchen, wenn die die ID nicht mal kennt ? Besser gesagt : die Liste selbst kennt die ID ja auch nicht, aber die Elemente müssen sie kennen.

[Daniel]

Ich fürchte, Ihr redet aneinander vorbei.

Delphi-Quellcode:

TListe = class (TObjectList) 
  Daten : TDaten;
end;

Natürlich lässt sich dieser Codeblock kompilieren. Aber er ist so für sich genommen sinnlos. Man hat eine neue Klasse (TListe), die von TObjectlist abgeleitet ist und zusätzlich ein Feld "Daten" vom Typ "TDaten" enthält. Dieses Feld hat aber mit dem Listen-Inhalt nichts zutun. In diese Liste kann ich mittels Add() weiterhin Buttons, Balkonmöbel und Brausepulver reintun.

Wenn ich den Datentyp vorgeben will, kann ich das tun, brauche dann aber entweder Generics (Delphi 2009 oder später) oder eine angepasste Add-Methode.

[himitsu]

Zitat von Daniel:

oder eine angepasste Add-Methode.

siehe "mich" > #33
Und wenn wirklich nur dieser Objekttyp da rein soll, dann müßte man in die Add-Methode noch eine Typenprüfung reinmachen.

Aber mit Generics wär's schon was Schönes und leichter anpaßbar