Klasse implementiert ein Interface weniger, höherer Speicherverbrauch

[freimatz]

Hallo,
in einer sehr komplexen Anwendung habe ich bei einer Klasse ein Interface entfernt. Beispiel:

Delphi-Quellcode:

//vorher
TBla = class(TVorfahr, IBla1, IBla2, IBla3, IBla4)
//nachher
TBla = class(TVorfahr, IBla1, IBla2, IBla3)

Ich habe also IBla4 entfernt. Es wird auch nicht benötigt. Alles kompiliert. Alle tausende Tests (Unit-Tests und UI-Tests) laufen korrekt durch ausser einem. Jener bemängelt, dass die Anwendung mehr Speicher benötigt. Nicht viel, aber doch über der üblichen Schwankung.
Hat wer eine Ahnung woran das liegen könnte? Kann sich jemand ein Scenario vorstellen wie so was passieren kann?
(In anderen Fällen gab es schon mal eine Kreuzreferenz was dann durch "[weak]" oder Umstellung gelöst werden konnte. Aber sowas kann ich mir nicht vorstellen.)

[Kas Ob.]

Hi,

I think, even if IBla4 wasn't needed but its functions is being called, may be one of them return a reference counted class/object/interface, if such function being called from the object TBla directly then it will be handled as usual class function, but if it was called from something like IBla4 within TBla then reference counted will be invoked and memory will be cleaned earlier, not leaving it hanging there waiting the application to close.

[jaenicke]

Hast du wirklich nur in der Klassendefinition das Interface entfernt? Und wenn du es wieder hinzufügt, ist der Speicherverbrauch wieder normal?

Um welche Werte reden wir denn hier? Wie oft liegt die Klasse im Speicher und wie hoch sind dabei die Unterschiede im Verbrauch in absoluten Werten?

[freimatz]

Hallo,
ja ich habe nur diese id und das Komma entfernt. Die Werte sind so bei 3%. Das ist nicht recht viel. Dafür dass diese Klasse eine von 24 ist und nur dieses interface weg bekommt recht viel. Wie oft das tatsächlich ist und wie die absoluten Werte sind kann ich nicht sagen. Das genauer zu untersuchen war mir bislang zuviel Aufwand.
Ein Fall ist mir noch eingefallen: if not Supports(Klasse, IBla4) then ProduziereSpeicherLeck();
Solche "if not Supports" kommen tatsächlich vor. Sie dürften jedoch nie aufgerufen werden und führen nach then zu einem raise einer Exception.
Nun denn, mal schauen wie ich da weiter mache. Auf jeden Fall nicht mehr dieses Jahr
Danke für Eure Denkanstösse.

[Blup]

Mehr Speicherverbrauch 3% von was? Der gesamten Anwendung, der Klasse oder ...?
Unterstützt TVorfahr bereits IBla4?
Unterstützt ein Nachfahre von TBla IBLa4?

Jeder Nachfahren von TBLa der zusätzlich IBLa4 unterstützen, braucht eine eigene Liste von Interfaces.
Stimmt die Liste mit der von TBLa überein, wird vieleicht die selbe Liste verwendet.
Das könnte zumindest einen kleinen Unterschied im Speicherbedarf für die Klassen erklären.

[jaenicke]

Zitat von Blup:

Jeder Nachfahren von TBLa der zusätzlich IBLa4 unterstützen, braucht eine eigene Liste von Interfaces.
Stimmt die Liste mit der von TBLa überein, wird vieleicht die selbe Liste verwendet.

Ja, an so etwas habe ich auch gedacht. Allerdings fällt das normalerweise kaum ins Gewicht, weshalb ich nach genaueren Daten zum Speicherverbrauch gefragt hatte. Es wäre schon wichtig diesen Speichermehrverbrauch auf die einzelne Instanz umrechnen zu können.

Wenn es z.B. 100.000 Nachfahr-Objekte gibt, macht das einiges aus. Ist es nur eine einzelne Instanz, würde das nicht passen.

[rabatscher]

Also... soweit ich das sehe (bitte korrigieren, falls ich falsch liege.., wird für jedes Interface ein zusätzliches Feld im
Ojekt angelegt. (siehe TObject.InitInstance in system.pas) . D.h. Wenn das Interface
hinzugefügt wird, erhöht sich der Speicher dementsprechend um 4Byte pro angelegtes Ojekt.

Man kann sich den Speicherverbrauch einer Klasse/Objekt auch per "InstanceSize" anschauen....

Delphi-Quellcode:

unit Unit1;

interface

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

type
  IIntf1 = interface
   ['{6AB3BE8C-8605-4ED6-97DA-CEED84E5B9F4}']
   procedure Test1;
  end;

  IIntf2 = interface
   ['{A2614303-1914-4BBE-9D38-D306EF36B14B}']
   procedure Test2;
  end;

type
  TObj1 = class(TInterfacedObject, IIntf1)
  public
    procedure Test1;
    procedure Test2;
  end;

type
  TObj2 = class(TInterfacedObject, IIntf1, IIntf2)
  public
    procedure Test1;
    procedure Test2;
  end;

type
  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
var obj1 : TObj1;
    obj2 : TObj2;
begin
     obj1 := TObj1.Create;
     obj1.Test1;
     obj1.Free;

     obj2 := TObj2.Create;
     obj2.Test1;
     obj2.Free;
end;

{ TObj1 }

procedure TObj1.Test1;
begin
     ShowMessage('Obj1 size:' + IntToStr(InstanceSize));
end;

procedure TObj1.Test2;
begin
     ShowMessage('obj1 test2');
end;

{ TObj2 }

procedure TObj2.Test1;
begin
     ShowMessage('Obj2 size: ' + intToStr(InstanceSize));
end;

procedure TObj2.Test2;
begin
     ShowMessage('test2');
end;

end.

[himitsu]

Ein Interface zeigt auf eine Interfacetabelle, welche in der RTTI neben dem Objekt abgelegt wird, also ja, es kommt ein "Pointer" hinzu.

[Mavarik]

Zitat von rabatscher:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var obj1 : TObj1;
    obj2 : TObj2;
begin
     obj1 := TObj1.Create;
     obj1.Test1;
     obj1.Free;

     obj2 := TObj2.Create;
     obj2.Test1;
     obj2.Free;
end;

Ich hoffe das ist nur ein schnell runter getipptes Demo und nicht so wie Du TinterfacedObjects in Deinem Programm verwendest…

Obj1 und Obj2 müssen vom Interface type sein und natürlich nicht mit free freigegeben werden.

Mavarik

[rabatscher]

Natürlich ist das nur ein schnell runter getipptes Ding - und natürlich würde ich interfaces so nicht verwenden...
Die Mixtur kann schnell in die Hose gehen
Aber da ich hier ja nur in der "Objektwelt" bin muss ich ja das Ojbekt brav freigeben (solange ich die Interfaces nicht anrühre und
das RefCounting initiere ).