Posso verificare se il compilatore C # ha inserito una chiamata al metodo?

StackOverflow https://stackoverflow.com/questions/616779

Domanda

Sto scrivendo un gioco XNA in cui eseguo controlli di collisione per pixel. Il ciclo che controlla ciò lo fa spostando un ORing bit e bit bit ed è generalmente difficile da leggere e comprendere.

Vorrei aggiungere metodi privati ??come bool privato IsTransparent (int pixelColorValue) per rendere il ciclo più leggibile, ma non voglio l'overhead delle chiamate al metodo poiché questo è molto sensibile alle prestazioni codice.

C'è un modo per forzare il compilatore a incorporare questa chiamata o farò solo spero che il compilatore farà questa ottimizzazione?

Se non esiste un modo per forzarlo, esiste un modo per verificare se il metodo è stato incorporato, a parte leggere lo smontaggio? Il metodo verrà visualizzato in riflessione se è stato incorporato e non esistono altri chiamanti?

Modifica: Non posso forzarlo, quindi posso rilevarlo?

È stato utile?

Soluzione

No, non puoi. Inoltre, quello che decide di inline non è un compilatore VS che ti prende il codice e lo converte in IL, ma un compilatore JIT che prende IL e lo converte in codice macchina. Questo perché solo il compilatore JIT conosce abbastanza l'architettura del processore per decidere se inserire un metodo in linea è appropriato in quanto è un compromesso tra pipeline di istruzioni e dimensione della cache.

Quindi anche guardare in .NET Reflector non ti aiuterà.

Altri suggerimenti

  

" Puoi controllare   System.Reflection.MethodBase.GetCurrentMethod (). Name.   Se il metodo è inline, lo farà   restituisce il nome del chiamante   invece ".

- Joel Coehoorn

Esiste un nuovo modo per incoraggiare l'inserimento più aggressivo in .net 4.5 che è descritto qui: http://blogs.microsoft.co.il/blogs/sasha/archive/2012/01/20/aggressive -inlining-in-the-clr-4-5-jit.aspx

Fondamentalmente è solo una bandiera per dire al compilatore di essere in linea se possibile. Sfortunatamente, non è disponibile nell'attuale versione di XNA (Game Studio 4.0) ma dovrebbe essere disponibile quando XNA raggiungerà VS 2012 quest'anno un po 'di tempo. È già disponibile se in qualche modo stai utilizzando Mono. 

[MethodImpl(MethodImplOptions.AggressiveInlining)] 
public static int LargeMethod(int i, int j)
{ 
    if (i + 14 > j) 
    { 
        return i + j; 
    } 
    else if (j * 12 < i) 
    { 
        return 42 + i - j * 7; 
    } 
    else 
    { 
        return i % 14 - j; 
    } 
}

Ricorda che l'XBox funziona in modo diverso.

Un google ha scoperto questo:

" Il metodo inline che mitiga il sovraccarico di una chiamata di un metodo. JIT si trasforma in inline ciò che soddisfa le seguenti condizioni.

  • La dimensione del codice IL è di 16 byte o meno.
  • Il comando branch non viene utilizzato (se frase ecc.).
  • La variabile locale non è utilizzata.
  • La gestione delle eccezioni non è stata effettuato (prova, cattura, ecc.).
  • float non è usato come argomento o restituisce il valore di un metodo (probabilmente da Xbox 360, non applicato).
  • Quando due o più argomenti sono in a metodo, utilizza per il turno dichiarato.

Tuttavia, una funzione virtuale non viene trasformata in inline. "

http: //xnafever.blogspot .com / 2008/07 / inline-metodo-by-XNA-on-xbox360.html

Non ho idea se sia corretto. Chiunque?

No, non puoi.

Fondamentalmente, non puoi farlo nemmeno nella maggior parte dei compilatori C ++ moderni. inline è solo un'offerta per il compilatore. È libero di prenderlo o meno.

Il compilatore C # non esegue inline speciali a livello di IL. L'ottimizzatore JIT è quello che lo farà.

perché non usare un codice non sicuro (inline c come è noto) e usare i puntatori di stile c / c ++, questo è sicuro dal GC (cioè non influenzato dalla raccolta) ma ha le sue implicazioni di sicurezza (non posso usare per internet app di zona) ma è eccellente per il tipo di cose che sembra stiate cercando di ottenere soprattutto con le prestazioni e ancora di più con le matrici e le operazioni bit a bit?

per riassumere, vuoi prestazioni per una piccola parte della tua app? usa un codice non sicuro e usa puntatori, ecc. mi sembra l'opzione migliore

EDIT: un po 'un antipasto? http://msdn.microsoft.com/en-us /library/aa288474(VS.71).aspx

L'unico modo per verificarlo è ottenere o scrivere un profiler e collegarsi agli eventi JIT, inoltre è necessario assicurarsi che Inlining non sia disattivato come per impostazione predefinita durante la profilazione.

È possibile rilevarlo in fase di esecuzione con la suddetta chiamata GetCurrentMethod. Ma sembrerebbe un po 'uno spreco [1]. La cosa più semplice da fare sarebbe solo ILDASM MSIL e controllare lì.

Nota che questo è specifico per il compilatore che allinea la chiamata ed è trattato nei vari Reflection documenti su MSDN.

  

Se il metodo che chiama il metodo GetCallingAssembly viene espanso in linea dal compilatore (ovvero, se il compilatore inserisce il corpo della funzione nel linguaggio intermedio Microsoft (MSIL) emesso, anziché emettere una chiamata di funzione), l'assembly restituisce dal metodo GetCallingAssembly è l'assembly che contiene il codice inline. Questo potrebbe essere diverso dall'assembly che contiene il metodo originale. Per garantire che un compilatore non contenga un metodo che chiama il metodo GetCallingAssembly, è possibile applicare l'attributo MethodImplAttribute con MethodImplOptions.NoInlining.

Tuttavia, JITter è anche libero di effettuare chiamate in linea, ma penso che un disassemblatore sarebbe l'unico modo per verificare ciò che è e non viene fatto a quel livello.

Modifica: solo per chiarire un po 'di confusione in questo thread, csc.exe sarà inline le chiamate MSIL - sebbene JITter (probabilmente) sarà più aggressivo in esso.

[1] E, per spreco, intendo che (a) che sconfigge lo scopo del rivestimento (prestazioni migliori) a causa della ricerca Riflessione. E (b), probabilmente cambierebbe il comportamento in linea in modo che non sia più in linea comunque. E, prima di pensare che puoi semplicemente attivarlo su build di debug con un Assert o qualcosa del genere, renditi conto che non sarà incorporato durante il debug, ma potrebbe essere in versione.

  

C'è un modo per forzare il compilatore a incorporare questa chiamata o farò solo spero che il compilatore farà questa ottimizzazione?

Se è più economico integrare la funzione, lo farà. Quindi non preoccuparti a meno che il tuo profiler non dica che in realtà è un problema.

Per ulteriori informazioni

Miglioramenti di JIT in .NET 3.5 SP1

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top