Problema de Rendimiento de la Interfaz Delphi

Estás comparando naranjas con manzanas, ya que la primera prueba lee un campo (FArr), mientras que la segunda prueba lee una propiedad (Arr) que tiene un getter asignado con ella. Por desgracia, las interfaces no ofrecen acceso directo a sus campos, por lo que realmente no puede hacerlo de otra manera que como lo hizo. Pero como dijo Allen, esto causa una llamada al método getter (getArray), que se clasifica como 'virtual' sin siquiera escribirlo porque es parte de una interfaz. Por lo tanto, cada acceso resulta en una búsqueda VMT (indirectamente a través de la interfaz) y una llamada al método. Además, el hecho de que esté utilizando una matriz dinámica significa que tanto el llamante como el destinatario harán mucho recuento de referencias (puede ver esto si echa un vistazo al código de ensamblado generado).

Todo esto ya es razones suficientes para explicar la diferencia de velocidad medida, pero de hecho se puede superar fácilmente usando una variable local y leer el array solo una vez. Cuando haces eso, la llamada al getter (y toda la referencia de seguimiento contando) se está llevando a cabo solo una vez. En comparación con el resto de la prueba, esta 'sobrecarga' se vuelve inconmensurable.

Pero tenga en cuenta que una vez que vaya por esta ruta, perderá la encapsulación y cualquier cambio en el contenido de la matriz NO se reflejará de nuevo en la interfaz, ya que las matrices tienen un comportamiento de copia al escribir. Sólo una advertencia.

Las respuestas de Patrick y de Allen son ambas perfectamente correctas.

Sin embargo, dado que su pregunta habla sobre el diseño mejorado de OO, creo que es apropiado discutir un cambio particular en su diseño que también mejoraría el rendimiento.

El código para establecer la etiqueta es "muy controlador". Lo que quiero decir con esto es que estás pasando mucho tiempo "husmeando dentro de otro objeto" (a través de una interfaz) para calcular el valor de tu etiqueta. Esto es realmente lo que exposed the"performance problem with interfaces".

Sí, simplemente puede deferir la interfaz una vez a una variable local y obtener una mejora masiva en el rendimiento, pero todavía estará husmeando dentro de otro objeto. Uno de los objetivos importantes en el diseño OO es no husmear donde no perteneces. Esto en realidad viola la Ley de Deméter .

Considere el siguiente cambio que faculta a la interfaz para hacer más trabajo.

IMyInterface = interface
['{C0070757-2376-4A5B-AA4D-CA7EB058501A}']
  function GetArray: TArrayOfRecord;
  function GetTagValue: Integer; //<-- Add and implement this
  property Arr: TArrayOfRecord read GetArray;
end;

function TMyObject.GetTagValue: Integer;
var
  I: Integer;
begin
  for i := 0 to High(FArr) do
    if (FArr[i].Val1 < FArr[i].Val2) or
       (FArr[i].Val3 < FArr[i].Val4) then
    begin
      Result := FArr[i].Val1 + FArr[i].Val2 - 
                FArr[i].Val3 + FArr[i].Val4;
    end;
end;

Luego dentro de TForm3.FormCreate, / / LA APROXIMACIÓN 3 se convierte en:

Tag := MyInterface.GetTagValue;

Esto será tan rápido como la sugerencia de Allen, y será un mejor diseño.

Sí, soy plenamente consciente de que simplemente armó un ejemplo rápido para ilustrar la sobrecarga de rendimiento de buscar repetidamente algo a través de la interfaz. Pero el punto es que si el código tiene un rendimiento subóptimo debido a accesos excesivos a través de interfaces, entonces tiene un olor a código que sugiere que debe considerar mover la responsabilidad de cierto trabajo en una clase diferente. En su ejemplo TForm3fue altamente inapropiado considerando todo requerido para el cálculo pertenecía a TMyObject.

Su diseño utiliza una memoria enorme. Optimiza tu interfaz.

IMyInterface = interface
  ['{C0070757-2376-4A5B-AA4D-CA7EB058501A}']
    function GetCount:Integer:
    function GetRecord(const Index:Integer):TRecord;   
    property Record[Index:Integer]:TRecord read GetRecord;
  end;