Se sostituisco tutti i riferimenti agli oggetti nel mio programma Delphi con i riferimenti all'interfaccia e utilizzo gli oggetti ereditati da TInterfacedObject, l'applicazione risultante verrà eseguita con la stessa velocità di prima? O il conteggio dei riferimenti aggiunge un sovraccarico di esecuzione significativo in fase di esecuzione?Quale effetto hanno le interfacce sulla velocità di esecuzione in Delphi?
Il conteggio dei riferimenti può influire su di voi se si eseguono molte assegnazioni di tali interfacce (o le si passano come parametri non const, non var in chiamate di funzione).
Tuttavia il vero problema spesso non è il riferimento che conta in sé, ma il try-finally implicita costruisce il compilatore aggiunge per proteggere il conteggio di riferimento, che si sommano alle chiamate in testa, e può essere più dolorosa se si dispone di molti semplici metodi (rispetto a un'unica grande procedura con tutto il codice all'interno, che non si vuole veramente).
Per attenuare questo aspetto, passare sempre le interfacce come parametri const o var, evitare di restituire interfacce come risultato di chiamata di funzione e ridurre l'utilizzo di variabili locali del tipo di interfaccia, preferire parametri const e usi campo diretto dell'oggetto.
classi interfacciato siano portatori di un overhead di incrementare e rilasciando il conteggio di riferimento di ogni istanza che si crea, passano e distruggono, ma a meno che non si sta creando, distruggendo e passando i riferimenti a cicli stretti, non si dovrebbero verificare alcun significativo rallentamento .
Ovviamente si può disabilitare il conteggio dei riferimenti in quanto tale restituendo -1 nel _AddRef e _Release prevale, ma ciò non impedisce al compilatore di generare quelle chiamate ...
Non solo il conteggio dei riferimenti - basta chiamare i metodi dell'oggetto tramite riferimento all'interfaccia implica sempre un sovraccarico. Here è possibile leggere come vengono chiamati i metodi dell'oggetto tramite il riferimento all'interfaccia in Delphi.
Quindi (oltre all'uso nelle interfacce) un blocco try finally' avrebbe anche un effetto significativo sulla velocità, anche se non si verificano eccezioni? – mjn
Sì, soprattutto nelle procedure semplici, perché un try-finally rappresenta un bel po 'di codice (a livello di ASM) e impedisce al compilatore di generare il codice di entrata e uscita più efficiente. Per esempio, verifica questo, è un caso di un codice di protezione implicita alla prova che non viene nemmeno eseguito, perché implicitamente try-finally sono collegati al compilatore alla procedura in cui si trovano e non al codice che può fallire . Quindi lo paghi nelle chiamate di procedura, anche se non esegui il codice che può fallire. http://delphitools.info/2009/05/06/code-optimization-go-for-the-jugular/ –
Ho appena letto di nuovo la tua risposta - una domanda su 'evitare di restituire interfacce come risultato di chiamata di funzione', fa questo significa che per esempio una funzione Factory non dovrebbe restituire oggetti tramite riferimenti all'interfaccia ma istanze di classe? Quindi 'TSomeFactory.CreateX' dovrebbe avere' TMyImplementationOfX' e non l'interfaccia 'IX' come tipo restituito? – mjn