Hvorfor er offentlige områder raskere enn egenskaper?

stemmer
38

Jeg var poking rundt i XNA og så at Vector3klassen i det var ved hjelp av offentlige områder i stedet for egenskaper. Jeg prøvde en rask benchmark og fant at for en structforskjellen er ganske dramatisk (legge to vektorer sammen 100 millioner ganger tok 2.0S med egenskaper og 1,4S med felt). For en referansetype, betyr forskjellen ikke synes å være så stor, men det er der.

Så hvorfor er det? Jeg vet at en eiendom er kompilert inn get_Xog set_Xmetoder, noe som ville medføre en metode samtale overhead. Men ikke disse enkle getters / settere alltid komme i foret av JIT? Jeg vet du kan ikke garantere hva JIT bestemmer seg for å gjøre, men sikkert dette er ganske høyt på listen av sannsynlighet? Hva annet er det som skiller en offentlig felt fra en eiendom på maskinen nivå?

Og en ting jeg har lurt: hvordan er en auto-implementert eiendom ( public int Foo { get; set; }) 'bedre' OO-design enn en offentlig feltet? Eller bedre sagt: hvordan er de to forskjellige ? Jeg vet at det å gjøre det en eiendom er enklere med refleksjon, men noe annet? Jeg vedder på at svaret på begge spørsmålene er det samme.

BTW: Jeg bruker .NET 3.5 SP1 som jeg tror faste saker hvor metoder med structs (eller metoder for structs, jeg er ikke sikker) var ikke i foret, så det er ikke det. Jeg tror jeg bruker det minst, det er sikkert installert, men da igjen, jeg bruker Vista 64-bit med SP1 som bør ha DX10.1 bortsett fra at jeg ikke har DX10.1 ..

Også: ja, jeg har kjørt en utgivelse bygge :)

EDIT : Jeg setter pris på raske svar folkens, men jeg merket at jeg ikke vet at en eiendom tilgang er en metode samtale, men jeg vet ikke hvorfor, formodentlig, metoden er tregere enn en direkte felttilgang i foret.

EDIT 2 : Så jeg laget en annen structsom brukes eksplisitt GETX () metoder (o hvordan jeg ikke savner min Java dager på alle ) og som utførte det samme om jeg deaktivert i-taket på det (gjennom [MethodImplAttribute(MethodImplOptions.NoInlining)]) eller ikke, så konklusjon: ikke-statiske metoder er tydeligvis aldri inlined, ikke engang på structs.

Jeg tenkte at det var unntak, der JIT kan optimaliserer den virtuelle metoden samtale unna. Hvorfor kan ikke dette skje på structs som kjenner noen arv og dermed en metode samtale kan bare peke på en mulig metode, ikke sant? Eller er det fordi du kan implementere et grensesnitt på den?

Dette er slags synd, siden det vil virkelig gjøre meg tenke på å bruke egenskapene på ytelsen kritiske ting, men ved hjelp av felt gjør meg føler meg skitten og jeg kan like godt skrive hva jeg gjør i C.

EDIT 3 : Jeg fant dette oppslaget nøyaktig samme emne. Hans slutten konklusjon er at eiendommen samtalen gjorde få optimalisert unna. Jeg kunne også ha sverget på at jeg har lest mange ganger at enkle getter / setter-egenskaper vil komme i foret, til tross for at callvirti IL. Så skal jeg gal?

EDIT 4 : Reed Copsey postet svaret i en kommentar nedenfor:

Re: Edit3 - se min oppdaterte kommentar: Jeg tror dette er x86 JIT vs x64 JIT problemer. JIT i x64 er ikke så moden. Jeg forventer MS for å forbedre dette raskt etter hvert som flere 64 bits systemer kommer på nettet hver dag. - Reed Copsey

Og mitt svar til hans svar:

Takk, dette er svaret! Jeg prøvde å tvinge en x86 bygge og alle metoder er like rask, og mye raskere enn x64. Dette er veldig sjokkerende for meg faktisk, hadde jeg ingen anelse om jeg levde i steinalderen på min 64-bit OS .. Jeg skal ta din kommentar på mitt svar så det skiller seg ut bedre. - JulianR

Takk alle sammen!

Publisert på 11/03/2009 klokken 00:24
kilden bruker
På andre språk...                            


5 svar

stemmer
15

Edit 2:

Jeg hadde en annen potensiell tanke her:

Du nevnte at du kjører på x64. Jeg har testet det samme problemet på x86, og sett samme ytelse når du bruker auto-egenskaper i forhold til felt. Men hvis du ser deg rundt på Connect og adresseliste / foruminnlegg, er det mange referanser på nettet til det faktum at x64 CLR er JIT er en annen kode base, og har svært forskjellige ytelseskarakteristikker til x86 JIT. Min gjetning er at dette er et sted hvor x64 er fortsatt henger etter.

Også, FYI, struct / metode / etc ting fast i .net 3.5sp1 var på x86 siden, og var det faktum at metodekall som tok structs som parameter aldri ville bli inlined på x86 før .net3.5sp1. Det er ganske mye irrelevant for denne diskusjonen på systemet ditt.


Edit 3:

En annen ting: Om hvorfor XNA bruker felt. Jeg var faktisk på Game Fest der de annonserte XNA. Rico Mariani holdt en tale der han tok opp mange av de samme punktene som er på sin blogg. Det synes XNA folk hadde lignende ideer når de utviklet noen av de viktigste stedene. Se:

http://blogs.msdn.com/ricom/archive/2006/09/07/745085.aspx

Spesielt, sjekk ut punkt # 2.


Som for hvorfor automatiske egenskaper er bedre enn offentlige områder:

De lar deg endre implementering i v2 av klassen, og legge logikk inn i eiendom får / faste rutiner som trengs, uten å endre grensesnittet til sluttbrukerne. Dette kan ha en dyp effekt på din evne til å opprettholde biblioteket og koden over tid.

---- Fra opprinnelige innlegget - men oppdaget dette var ikke problemet --------

Ble du kjører en utgivelse bygge utenfor av VS? Det kan være en forklaring på hvorfor ting ikke blir optimalisert. Ofte, hvis du kjører i VS, selv en optimalisert utgivelse bygge, deaktiverer VS vertsprosessen mange funksjoner i JIT. Dette kan føre til ytelsestester for å endre.

Svarte 11/03/2009 kl. 00:26
kilden bruker

stemmer
5

Du bør lese denne artikkelen ved Vance. Det går i detalj om hvorfor metoder ikke alltid inlined av JIT'er selv om det ser helt tydelig at de skal være.

http://blogs.msdn.com/vancem/archive/2008/08/19/to-inline-or-not-to-inline-that-is-the-question.aspx

Svarte 11/03/2009 kl. 00:27
kilden bruker

stemmer
3

Tilgang til et felt er bare en lagerreferanse, mens ved anvendelse av en egenskap er faktisk påkaller en fremgangsmåte og omfatter funksjonsoppropet overhead. Grunnen til å bruke egenskapene fremfor felt er å isolere koden fra endringer og gi bedre detaljnivå over tilgangen. Ved å ikke utsette feltet direkte har du større kontroll over hvordan tilgangen er gjort. Ved hjelp av automatiske felt gjør at du kan få den typisk getter / setter atferd, men bygger på muligheten til å endre dette uten en påfølgende behov for at endringene skal forplante seg til andre deler av koden.

For eksempel si at du ønsker å endre koden slik at tilgang til et felt er kontrollert av den aktuelle brukerens rolle. Hvis du hadde utsatt feltet offentlig, vil du være nødt til å berøre alle deler av koden som vist det. Utsette det gjennom en eiendom kan du endre eiendommen kode for å legge til nye krav , men ikke resulterer i unødvendige endringer til noen kode som åpner den .

Svarte 11/03/2009 kl. 00:31
kilden bruker

stemmer
3

XNA må målrette XBox 360, og JIT i .NET Compact Framework er ikke så avansert som sin desktop motstykke. .NET CF JIT'er vil ikke inline eiendoms metoder.

Svarte 11/03/2009 kl. 00:30
kilden bruker

stemmer
3
  • Offentlige områder er direkte oppdrag
  • Egenskaper er metoder, deretter mer kode, ubetydelige, men flere.
Svarte 11/03/2009 kl. 00:25
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more