2012-03-26 10 views
5

Se ci sono n proprietà, allora è il Big-O di .GetProperties O (n) o ci sono processi coinvolti nella riflessione che aggiungono complessità?Big-O di .GetProperties()

dire che c'è questa classe definita:

public class Reflector 
{ 
public string name { get; set; } 
public int number { get; set; } 
public bool flag { get; set; } 
public List<string> etc { get; set; } 
} 

E poi questo chiamata viene effettuata:

var reflect = new Reflector(); 
PropertyInfo[] properties = reflect.GetType().GetProperties(); 

Qual è la complessità di tempo, vale a dire O-grande, di .GetProperties()? Considerando che ci sono 4 proprietà, questo richiederebbe solo 4 iterazioni o è più complesso di così? Oppure, è O (1) con qualche serie standard di complessità per arrivare alla lista - che sembra che debba essere ancora O (n) solo per costruire l'array delle proprietà?

+0

Per le iterazioni di cosa? .. Possono esserci zero iterazioni, se l'array è predisposto per voi. – dasblinkenlight

+0

@dasblinkenlight - iterazioni del processo interno utilizzato per generare l'elenco delle proprietà. Per quella parte della domanda, e dalle risposte in basso, penso che la risposta fosse "più complessa". –

risposta

3

Big-O riguarda la complessità asintotica, in altre parole O (n) è rilevante solo per i grandi valori di n.
Una classe non avrà mai abbastanza proprietà per renderla rilevante.

Per scopi pratici, si potrebbe anche considerare O (1), ma con una costante molto grande.

Questo tipo di problema è espresso in nanosecondi, non in notazioni Big-O.

+0

Mi rendo conto che potrei averlo formulato in modo improprio, quello che stavo cercando di ottenere era la complessità algoritmica interna della riflessione. –

+0

Grazie, farò una domanda diversa basata sui nanosecondi di riflessione - o cercherò di vedere se ne esiste una. –

+0

Il tempo sarà nella forma 'T = A + B * n', Stimo A >> B ma dovrai misurare. E probabilmente dipenderà da molti fattori, come le classi base, le chiamate Reflection precedenti, ecc. –

3

Più complicato di così. L'algoritmo deve includere anche la catena del tipo di base. Inoltre, l'implementazione potrebbe memorizzare nella cache il risultato, quindi il costo ammortizzato potrebbe essere effettivamente O (1).

Ma in pratica, la riflessione è sempre piuttosto lenta, quindi probabilmente dovresti profilare la tua applicazione e apportare modifiche finché non raggiungi i tuoi obiettivi di rendimento.

+0

Cosa lo rende 'sempre piuttosto lento? –

+1

@TravisJ onestamente, non ho una ragione specifica. La mia esperienza personale nello sviluppo del framework ASP.NET MVC e nell'essere responsabile di alcune delle ottimizzazioni delle prestazioni in esso è che di solito otteniamo prestazioni più elevate se in qualche modo possiamo memorizzare le informazioni derivate dalla riflessione invece di eseguire sempre la stessa riflessione. La mia intuizione sul perché potrebbe essere è perché il framework non è semplicemente ottimizzato con questo in mente (dopotutto, è un runtime compilato staticamente). – marcind

Problemi correlati