În .NET, vor fi golite apelurile metodelor să fie optimizate?

Având un corp de metodă gol, JIT va optimiza apelul (știu că compilatorul C# nu va). Cum aș putea să aflu? Ce instrumente ar trebui să utilizez și unde ar trebui să fiu în căutarea?

Deoarece sunt sigur că va fi întrebat, motivul metodei goale este o directivă preprocesor.


@Chris: Are sens, dar ar putea optimiza apelurile la metodă. Deci, metoda ar mai exista, dar apelurile statice la aceasta ar putea fi eliminate (sau cel putin inliniate ...)

@Jon: Asta îmi spune că compilatorul de limbi nu face nimic. Cred că trebuie să-mi dau drumul prin ngen și să mă uit la adunare.

0
fr hi bn

5 răspunsuri

Nu, metodele goale nu sunt niciodată optimizate. Iată câteva motive pentru care:

  • Metoda poate fi apelată de la a clasa derivată, probabil într-o diferite tipuri de asamblare
  • Metoda ar putea să fie apelat prin Reflecție (chiar dacă este marcat privat)

Editare: Da, din perspectiva proiectului (cod exellent) doc, JITer va elimina apelurile la metodele goale. Dar metodele în sine vor fi încă compilate și vor fi incluse în binar pentru motivele pe care le-am enumerat.

0
adăugat

Cred că codul dvs. este ca:

void DoSomethingIfCompFlag() {
#if COMPILER_FLAG
    //your code
#endif
}

Acest lucru nu va fi optimizat, cu toate acestea:

partial void DoSomethingIfCompFlag();

#if COMPILER_FLAG
partial void DoSomethingIfCompFlag() {
    //your code
}
#endif

Prima metodă goală este parțială, iar compilatorul C# 3 o va optimiza.


Apropo: aceasta este în esență ceea ce sunt metode parțiale pentru. Microsoft a adăugat generatoare de cod la designerii lor Linq care au nevoie să apeleze metode care în mod implicit nu fac nimic.

Mai degrabă decât să vă forțeze să supraîncărcați metoda, puteți folosi o parte.

În acest fel, partialii sunt complet optimizați dacă nu sunt utilizați și nu se pierde nici o performanță, mai degrabă decât adăugarea costurilor suplimentare ale apelului pentru metoda extra gol.

0
adăugat
Utilizarea atributului [Conditional ("COMPILER_FLAG")] va avea același efect și poate poate fi ușor de utilizat. Consultați msdn.microsoft.com/en-us/library/4xssyw96.aspx
adăugat autor Eric, sursa

Acest chap are un tratament destul de bun pentru optimizările JIT, face o căutare pe pagină pentru că "metoda este goală", este cam la jumătatea drumului în jos al articolului -

http://www.codeproject.com/KB/dotnet/JITOptimizations.aspx

Metodele aparent goale se optimizează prin introducerea faptului că în realitate nu există cod.

@Chris: Îmi dau seama că metodele vor fi în continuare parte din binar și că acestea sunt optimizări JIT :-). Pe o notă semi-legată, Scott Hanselman a avut un articol destul de interesant despre introducerea în stivele de lansare a apelurilor de lansare:

http://www.hanselman.com/blog/ReleaseISNOTDebug64bitOptimizationsAndCMethodInliningInReleaseBuildCallStacks.aspx

0
adăugat

Toate lucrurile fiind egale, da, ar trebui optimizate. JIT inline funcționează acolo unde este cazul și există puține lucruri mai potrivite decât funcțiile goale :)

Dacă într-adevăr doriți să fiți siguri, atunci schimbați metoda goală pentru a arunca o excepție și pentru a tipări traseul de stivă pe care îl conține.

0
adăugat

@Jon Limjap: Știm deja că compilatorul C# nu optimizează metodele goale. Deoarece ceea ce decompilați cu ialasmul a fost generat de compilatorul C# ... fără ajutor acolo.

0
adăugat