Optimal løsning for struct med mer enn 16 byte

stemmer
3

Jeg har en type som jeg anser bruke det som struct.

  • Det representerer enkeltverdi
  • Det er uforanderlige

Men problemet er, det har 6 felt av int.

Så hvilken løsning jeg skal bruke for denne typen?

  1. fortsette å bruke struct?
  2. endre til klasse?
  3. eller pakke 6 heltall inn i en matrise av int, slik at det har bare ett felt

REDIGERE

Størrelsen på struct med 6 heltallsfeltene er 24 bytes, som er stort til å passere rundt. Anbefal størrelse for struct er ikke mer enn 16 byte

Publisert på 04/01/2009 klokken 07:32
kilden bruker
På andre språk...                            


7 svar

stemmer
5

Det avhenger av hvordan du skal bruke det?

  1. Har du tenkt å fordele mye av det vs. passerer det rundt mye?
  2. Er det kommer til å bli fortært av tredje part koden? I dette tilfellet klassene vanligvis gi deg mer fleksibilitet.
  3. Ønsker du struct kontra klasse semantikk? For eksempel, ikke-ha nullverdier?
  4. Vil du ha nytte av å ha et par pre-laget forekomster av denne klassen som kan gjenbruke å representere spesielle tilfeller? I likhet med String.Empty. I dette tilfellet ville du ha nytte av en klasse.

Det er vanskelig å svare bare fra informasjonen du har oppgitt i spørsmålet ditt.

Svarte 04/01/2009 kl. 07:51
kilden bruker

stemmer
1

Vær forsiktig med boksing. Hvis struct kommer til å bli fortært av en metode som forventer et objekt, vil det bli tvunget til et objekt og du har en potensiell ytelse hit.

Her er en referanse som forklarer det nærmere.

Jeg vil gjøre det til en klasse (# 2) og så ville du ikke trenger å bekymre deg for det.

Ved hjelp av en rekke på seks tall (# 3) vil trolig gjøre koden vanskeligere å lese. En klasse med beskrivende identifikatorer for hvert int ville være mye bedre.

Svarte 04/01/2009 kl. 08:13
kilden bruker

stemmer
0

Hvis dataene holderen kommer til å være uforanderlig, vil struct-versus-klasse spørsmålet mest sannsynlig være avhengig av gjennomsnittlig antall referanser som ville eksistere i hvert enkelt tilfelle. Hvis man har en rekke TwentyFourByteStruct [1000], vil denne matrisen ta 24.000 bytes, uavhengig av om hvert element har en annen verdi, alle elementer holde samme verdi, eller et sted i mellom. Hvis man har en rekke TwentyFourByteClass [1000], vil denne matrisen ta med 4000 eller 8000 byte (for 32/64-bits-systemer), og hver forekomst av distinkte TwentyFourByteClass som er opprettet vil ta omkring 48 byter. Hvis alle oppstillingselementene skje for å holde en referanse til den samme TwentyFourByteClass objekt, vil den totale være 4048 eller 8,048 bytes. Hvis alle oppstillingselementene holder referanser til forskjellige TwentyFourByteClass objekter, vil den totale være 52.000 eller 56.000 byter.

Som for run-time ytelse, vil den beste ytelsen du kan få vanligvis passerer strukturer som referanse. Passerer strukturer av verdi vil kreve kopiere dem, noe som kan bli kostbart for strukturer som er større enn 16 byte (.net omfatter optimaliseringer for konstruksjonene 16 byte eller mindre), men kostnaden for en verdi type ved referanse er den samme uansett om det er en byte eller 16.000 bytes.

Svarte 06/10/2011 kl. 16:38
kilden bruker

stemmer
0

Jeg foreslår at du skriver en liten målestokk for å måle ytelsen til de ulike alternativene, er dette den eneste måten å vite sikkert. Du kan bli overrasket over resultatene (jeg ofte er).

(Jeg antar at din bekymring her er resultatene.)

Svarte 30/06/2010 kl. 19:36
kilden bruker

stemmer
0

Hva med en WriteOnce<int[]>?

Svarte 04/01/2009 kl. 07:44
kilden bruker

stemmer
0

Uten å se din struct, er det vanskelig å si noe definitivt. Men jeg mistenker at du bør la dette som en struct.

Svarte 04/01/2009 kl. 07:40
kilden bruker

stemmer
-1

Generelt, ved lagring av mer enn to deler av relaterte data jeg ønsker å lage en klasse som binder dem sammen. Spesielt hvis jeg vil sende dem rundt som en enhet.

Svarte 04/01/2009 kl. 09:04
kilden bruker

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