Datenstruktur: Kindobjekt als Objekt oder Record

[Der schöne Günther]

Es sind doch nur Daten, sie tun nichts. "Plain Old Data", in Delphi praktisch immer ein Record, z.B. TMySettings .

Deinem tatsächlichen Objekt verpasst du nicht fünf Dutzend Properties, sondern du kannst die TMySettings lesen, und du kannst sie setzen. Später willst du diese Einstellungen dauerhaft speichern und laden oder übers Netz übertragen, und kümmerst dich um die Serialisierung von TMySettings . Wer oder was das benutzt ist unerheblich.

Wenn du wirklich meinst dass sich messbare Performance-Einbußen über das Pass by value ergeben lässt sich das ganze ja notfalls auch noch über einen Referenztyp wrappen, aber die Daten selbst - Da sehe ich nie was man dadurch gewinnt, das in ein TObject oder gar interface-basiertes Objekt zu verpacken, außer noch mehr Tipparbeit und Komplexität.

[Friday]

Zitat von Der schöne Günther:

Deinem tatsächlichen Objekt verpasst du nicht fünf Dutzend Properties, sondern du kannst die TMySettings lesen, und du kannst sie setzen.

Du sprichst dich also für die Lösung von TiGü aus. Aber wie gesagt, das funktioniert nicht weil TMyObj mind. 2 Interfaces als properties hat.

[Der schöne Günther]

Ich stehe auf dem Schlauch - Inwiefern ist das ein Problem?

[Uwe Raabe]

Zitat von Der schöne Günther:

Ich stehe auf dem Schlauch

Kann ich mich anschließen. Allerdings habe ich überhaupt noch nicht verstanden, was denn eigentlich erreicht werden soll. Im Moment sehe ich nur vage Fetzen vom Ganzen und ich will mir den Rest nicht einfach dazu denken.

[TiGü]

Bin auch Schlauchsteher!
Welches technische Problem steht dem im Weg?

[stahli]

Grundsätzlich stellt sich ja die Frage:

- Warum soll ich ein Object, InterfacedObject oder Record verwenden?

Alles hat Vor- und Nachteile.

Ein Record ist schlank aber bei Übergaben werden die Values normalerweise kopiert, was langsam sein kann (wenn man nicht Pointer benutzt).
Ein InterfacedObject ist langsam und speicherhungrig. Dafür kann man sie leicht referenzieren, sie "teilen Funktionalitäten" und sie können automatisch freigegeben werden.
Ein Object ist nicht ganz so langsam und speicherhungrig, kann leicht referenziert werden, unterstützt Vererbung, muss aber freigegeben werden.

Für Eigenschaften Deiner Klasse stellt sich die gleiche Frage.
Interface-Funktionalitäten brauchst Du dafür offenbar nicht - also kannst Du Dir den Aufwand sparen.
Bleiben Records und Klassen.
Wenn Du diese ständig weitergeben musst, würden sich wohl Klassen anbieten, ansonsten Records.

[Friday]

Zitat von Der schöne Günther:

Ich stehe auf dem Schlauch - Inwiefern ist das ein Problem?

Der auf dem Schlauch steht bin wohl ich selbst
Hatte das mehrfach gelesen, aber immer falsch verstanden. Records können natürlich keine Interfaces implementieren im Sinne von
MyRec = Record(IMyInterface) Aber sehr wohl interfaces als Felder oder properties haben.

OK...also nochmal weniger das gegen Records spricht.

Aber wie seht ihr das Argument den Stack nicht unnötig mit langlebigen Daten zu befüllen? (Die noch dazu keinen Geschwindigkeitsvorteil benötigen weil selten kopiert)

[Der schöne Günther]

Auf einem PC (im Gegensatz zu einem kleinen Mikrocontroller) muss man echt schon einiges anstellen um den Stack voll zu bekommen. Standardmäßig ist die Stack-Größe (pro Thread) in Delphi bei 1 Megabyte (lässt sich einstellen).

Ich bin kein Compiler/Assemblercode-Experte, aber ich würde dem Compiler durchaus zutrauen dass er die Register bzw. den Memory für den Stack wiederverwendet und bei z.B. 5 dicken Records nicht fünf mal allokiert. Und: Wenn man die Daten als const oder [Ref] übergibt, dann optimiert der Compiler das dorthin gehend, dass die Daten nur per Zeiger übergeben werden.

[mytbo]

Zitat von Friday:

Aber wie seht ihr das Argument den Stack nicht unnötig mit langlebigen Daten zu befüllen?

Ich weiß nicht, warum du dir Sorgen um den Stack machst. So wie ich deine Anforderung verstanden habe, wird es vermutlich mit einem "array of ..." enden und damit landest du auf dem Heap. Auf dem Heap werden angelegt: Klassen, dynamische Arrays, alle gemanagten Typen (String, Variant, Interface) und Speicher der mit GetMem() oder New() angefordert wird. Daher funktioniert auch Folgendes problemlos:

Delphi-Quellcode:

uses
  mormot.core.base,
  mormot.core.data,
  mormot.core.text,
  mormot.core.json,
  mormot.core.unicode,
  mormot.core.variants,
  mormot.core.os,
  mormot.core.perf;

procedure SpeedTestRecords;
type
  TSubItem = record
    id: Integer;
    value: RawUtf8;
  end;
  TDataItem = record
    id: Integer;
    value: RawUtf8;
    subItem: TSubItem;
  end;
  TDataItems = array of TDataItem;
var
  json, xml: RawByteString;
  timer: TPrecisionTimer;
  items: TDataItems;
begin
  SetLength(items, 1000000);
  for var i: Integer := Low(items) to High(items) do
  begin
    items[i].id := i;
    items[i].value := StringToUtf8('value' + i.ToString);
    items[i].subItem.id := i;
    items[i].subItem.value := StringToUtf8('subItem_value' + i.ToString);
  end;

  timer.Start;
  json := DynArraySaveJson(items, TypeInfo(TDataItems));
  timer.Pause;
  FileFromString(json, '_testData.json');

  timer.Resume;
  xml := JsonToXML(json);
  timer.Pause;
  FileFromString(xml, '_testData.xml');

  WriteLn(Format('Total time: %s', [timer.Stop]));
end;

Habe ich schon erwähnt, dass mORMot diese 1M Records JSON und XML Serialisierung in 1 Sekunde schafft.

Bis bald...
Thomas