2009-10-07 14 views
5

le espressioni lambda semplici vengono sottolineate?farsi lambda in linea?

Ho la tendenza (grazie a f # e ad altre incursioni funzionali) di incapsulare il codice ripetuto presente all'interno di una singola funzione in una lambda e chiamarlo invece. Sono curioso di sapere se sto incorrere in un sovraccarico di run-time come risultato:

var foo = a + b; 
var bar = a + b; 

v

Func<T1, T2> op =() => a + b; 
var foo = op(); 
var bar = op(); 

quale costa di più a correre?

risposta

3

No. Le funzioni lambda non sono in linea, ma vengono memorizzate come delegati sotto il cofano e comportano lo stesso costo di esecuzione degli altri delegati.

+1

* sigh *. così tanto per quel piccolo trucco. Grazie. – kolosy

7

Per rispondere alla domanda sulla prestazione: eseguila un miliardo di volte in entrambe le direzioni. Misura il costo di ciascuno. Allora lo saprai. Non abbiamo idea di quale hardware stai usando, quale "rumore" è presente nei tuoi scenari rilevanti o cosa consideri una metrica di prestazioni importante. Sei l'unica persona che conosce quelle cose, quindi sei l'unica persona in grado di rispondere alla domanda.

Per rispondere alla domanda sul codecen: Jared è corretto ma la risposta potrebbe essere ampliata.

Prima di tutto, il compilatore C# mai fa inlining di alcun codice. Il compilatore jit fa l'inlining del codice, ma il fatto che il compilatore C# generi lambdas come istanze delegate significa che è improbabile che il jitter possa ragionevolmente incorporare questo codice. (Naturalmente è possibile per il jitter di fare questa analisi sofisticate per stabilire che lo stesso codice è sempre nel delegato, ma non credo che in pratica sono stati implementati gli algoritmi.)

Se si desidera il codice da inserire è quindi necessario scriverlo in linea. Se non vuoi scriverlo in linea ma lo vuoi ancora in linea, dovresti scriverlo come metodo statico e sperare che il jitter lo indichi.

Ma a prescindere, sembra un'ottimizzazione prematura. Scrivi il codice nel modo in cui vuoi scrivere il codice, quindi analizza le sue prestazioni, quindi riscrivi le cose lente.