procedure TComponent.RemoveComponent(AComponent: TComponent) ;
begin
Notification(AComponent, opRemove) ;
AComponent.SetReference(False) ;
Remove(AComponent) ;
AComponent.SetDesigning(False) ;
ValidateRename(AComponent, AComponent.FName, '') ;
end;
Notice at the beginning of this method the call to Notification (passing opRemove). Notification, as we've already seen above, is a iterative call and it's a virtual method. So the additionally unnecessary performance hit gets you twice. Once on creation and once on destruction. This performance hit can be completely avoided by passing nil as the parameter to our TTable instance that is locally created and freed.
-
When informed of this performance hit, it is sometimes suggested to use Application as the owner instead of Self (in the original code example "Self" was a TForm). This suggestion was based on the fact that statistically, the Application object will tend to own fewer components (e.g., just the auto-create forms), than a form would. While this may be true, passing the Application object as the owner actually has an even more severe impact on performance, because the Notification call iterates through each component owned by the owner. This means that every component on every form owned by the Application object will get it's Notification method called, in addition to every TComponent descendant owned by the Application directly.
