Overhead med å bruke dette på structs

stemmer
0

Når du har automatiske egenskaper, spør C # kompilatoren du å ringe thiskonstruktøren på noen konstruktør du har, for å sørge for at alt er initialisert før du tilgang til dem.

Hvis du ikke bruker automatiske egenskaper, men rett og slett erklære verdiene, kan du unngå å bruke thiskonstruktøren.

Hva er overhead for å bruke thispå konstruktører i structs? Er det det samme som dobbel initialisering verdiene?

Ville ikke anbefaler å bruke det, hvis ytelsen var en topp bekymring for denne typen?

Publisert på 26/05/2009 klokken 20:17
kilden bruker
På andre språk...                            


4 svar

stemmer
4

Jeg anbefaler ikke å bruke automatiske egenskaper i det hele tatt for structs, så det betyr at de vil være foranderlig - hvis bare privat.

Bruk skrivebeskyttet felt og offentlige eiendommer for å gi tilgang til dem der det er hensiktsmessig. Foranderlig strukturer er nesten alltid en dårlig idé, og har alle slags ekle små irritasjonsmomenter.

Har du absolutt trenger for å lage din egen verditype i første omgang selv? I min erfaring er det svært sjelden å finne en god grunn til å opprette en struct snarere enn en klasse. Det kan være at du har en, men det er verdt å sjekke.

Tilbake til det opprinnelige spørsmålet: Hvis du bryr deg om ytelse, måle det . Alltid. I dette tilfellet er det veldig enkelt - du kan skrive struct ved hjelp av en automatisk eiendommen og deretter reimplement det uten. Du kan bruke en #ifblokk å holde begge alternativer tilgjengelig. Deretter kan du måle typiske situasjoner og se om forskjellen er betydelig. Selvfølgelig tror jeg design implikasjonene er sannsynlig å være viktigere uansett :)

Svarte 26/05/2009 kl. 20:42
kilden bruker

stemmer
2

Ja, vil verdiene bli startet to ganger og uten profilering er det vanskelig å si hvorvidt denne ytelsen hit ville være betydelige.

Standard konstruktør av en structinitialiserer alle medlemmer til standardverdiene. Etter dette skjer din konstruktør vil kjøre der du utvilsomt sett verdiene av disse egenskapene igjen.

Jeg vil tro at dette ville være noe annerledes enn CLR praksis med initialisering alle felt av en referansetype på oppretting.

Svarte 26/05/2009 kl. 20:20
kilden bruker

stemmer
1

Ikke bruk automatiske eiendommer med strukturtypene. Bare utsett felt direkte. Hvis en struct har en utsatt offentlige feltet Fooav type Bar, er det faktum at Fooer en utsatt felt av typen Bar(informasjon lett tilgjengelig fra IntelliSense) forteller en stort sett alt som er å vite om det. I motsetning, det faktum at en struct Foohar en utsatt lese-skrive eiendom Bozsier ikke noe om hvorvidt du skriver til Bozvil mutere et felt i struct, eller om det vil mutere et objekt som Bozhar en referanse. Utsette felt direkte vil tilby renere semantikk, og ofte også føre til raskere å kjøre kode.

Svarte 29/09/2012 kl. 17:01
kilden bruker

stemmer
1

Grunnen til at C # kompilatoren krever at du kjeden til standardkonstruktør (dvs. legge : this()til konstruktøren erklæring) når auto-implementert egenskapene brukes er fordi alle variabler må være tildelt før du avslutter konstruktøren . Nå, auto-implementert egenskaper rotet dette opp litt i at de ikke lar deg direkte tilgang til de variablene som tilbake eiendommene . Metoden kompilatoren bruker for å komme seg rundt dette på er å automatisk tildele alle variablene til standardverdiene, og for å sikre dette, må du kjeden til standardkonstruktør. Det er ikke et spesielt smart metode, men den gjør jobben godt nok.

Så ja, vil dette bety at noen variabler vil ende opp med å få klargjort to ganger. Men jeg tror ikke dette vil være en stor ytelse problem. Jeg ville bli veldig overrasket over det kompilatoren (eller i det minste JIT) ikke bare fjerne den første initialisering setningen for alle variabler som er satt to ganger i konstruktøren. En rask benchmark bør bekrefte dette for deg, men jeg er ganske sikker på at du vil få de mistenkte resultater. (Hvis du ved en tilfeldighet ikke gjør det, og du trenger absolutt den lille ytelsen øke som unngår dupliserte initialisering tilbud, kan du bare definere dine egenskaper på vanlig måte, dvs. med backing variabler.)

For å være ærlig, vil mitt råd være ikke engang å bry seg med auto-implementert eiendommer i strukturer. Det er helt akseptabelt bare for å bruke offentlige variabler i stedet for dem, og de tilbyr ikke mindre funksjonalitet enn auto-implementert egenskaper. Klassene er en annen situasjon selvfølgelig, men jeg ville ikke nøle med å bruke offentlige variabler i structs. (Eventuelle komplekse egenskaper kan defineres som normalt, hvis du trenger dem.)

Håper det hjelper.

Svarte 26/05/2009 kl. 20:24
kilden bruker

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