[ALG/C#] Structs vs Object

[Scare360]

Ik heb een vrij zware calculatie, waarbij ik momenteel de getters van een handje vol objecten als input gebruik. Probleem 1 is dat dat nogal wat geheugen eet, probleem twee is dat ik na de calculatie maar eens n-aantal objecten daadwerkelijk gebruik. Ruim 80% laad ik dus voor jan doedel in mijn werkgeheugen. Is het verstandig (lees zinvol) de input in een struct te trekken? En zodra de resultaten bekend zijn pas de gevonden objecten in-memory te trekken? Dit betekend dan wel dat de structs met de input gegevens duplicatie gegevens bevatten aangezien de objecten deze ook encapsuleren.

Iemand een ideetje?

[Verwijderd]

Ik begrijp niet helemaal wat je bedoeld, misschien kan je wat code laten zien?

[whoami]

Ik denk niet dat een codevoorbeeld hier nodig is, het gaat nl. om een idee, en niet om een code-probleem.


Wat is er het snelst? Een value-type of een reference - type?

[Scare360]

Value heaperdepiep

[Soultaker]

Ik begrijp het probleem niet, maar ik kan dan ook geen C#: staan die structs niet ook in het geheugen? En als het antwoord 'ja' is, waarom zouden die structs dan minder ruimte innemen (op misschien een vtable pointer na)?

[SlowMeDown]

Het daadwerkelijk gebruiken (methods aanroepen etc.) van structs of objects scheelt niet in performance, wel het aanmaken en vernietigen van structs of objects. Dit omdat structs aangemaakt worden op de stack en objects aangemaakt worden op de heap.

De stack is een stuk efficienter dan de heap. Dus een boel structs aanmaken en vernietigen gaat sneller als dezelfde hoeveelheid objecten aanmaken en vernietigen. Waarbij de structs en objecten natuurlijk dezelfde fields/methods/properties/indexers hebben.

Als ik jou goed begrijp gebruik je een x aantal objecten waarvan je data gebruikt als input voor je berekening. Na de bereking heb je echter maar een paar van die objecten nodig.

Ik denk dat je weinig snelheidsverschil zult merken, juist omdat je de objecten alleen maar gebruikt als input voor je berekening. Als je in je berekening veel objecten zou aanmaken/vernietigen dan zou ik voor structs gaan, omdat die sneller zijn.

Als je echt krap zit met je geheugen, kunt je jouw berekening misschien uitbreiden, zodat bepaald kan worden wanneer een object niet meer nodig is (voor input) en dat object dan vernietigen. Of inderdaad alle input verzamelen in een struct/ander object/array of iets dergelijks en de objecten die uit de berekening rollen in de berekening zelf aanmaken.

Misschien heb je er wat aan, misschien ook niet....

[EfBe]

Eric Gunnerson, een van de designers van C# zei ooit: "Only use structs for complex value types like ComplexNumber. For the rest, use classes". Zegt genoeg denk ik

Structs zijn op zich aardig, maar erg gelimiteerd: je wilt ze vaak gebruiken als object maar dat kan niet, het zijn value types. Ze in een arraylist stoppen en ze dan daarin wijzigen bv kan niet: je moet eerst een copy maken, die wijzigen en daarna die copy over de oude heenzetten. (C# compiler gilt als je het direct wilt doen). Ik zou eerst goed kijken welke dat werkelijk nodig is voor de berekening, die binnenhalen, berekening doen en dan verder kijken wat je binnen moet halen. Maar misschien begrijp ik je verkeerd.

[Scare360]

Ik ben d'r uit... mijn probleem was... stel ik heb een magazijn met 200.000 zakken suiker. We gaan snoep maken. Er is een process wat een zak gebruikt. Het process weet welke zak gebruikt is, maar dan alleen de datum en hoeveelheid van de dosering (hoeveelheid suiker in het proces). Bepaal welke zak je gebruikt hebt.

Dan moet je dus alle processen en doseringen op halen binnen x-tijd, steeds de bijboekingen van de afboekingen optellen aftrekken en de hoeveelheid uit een zak gedoseerd is. uiteindelijk kom je dan op de goede zak uit. First in First out (FIFO), want je doseert de oude grondstoffen eerst.

Vandaar dat ik de vraag abstract gehouden heb, om de werkelijke voor/na-delen naar boven te halen.

[Soultaker]

De stack is natuurlijk niet bedoelt om gigantische hoeveelheden data op te alloceren. Je hebt doorgaans dan ook veel meer heap space dan stack space ter beschikking; als je veel objecten wilt alloceren kun je dat dan ook het beste op de heap doen.

Daarbij neemt de efficientie van de stack ten op zichte van de heap af als je 'm zo vol gaat proppen dat de zinnige inhoud ervan buiten de caches valt. Daardoor zou het ook wel eens efficienter kunnen zijn om grote aantallen grote objecten op de heap te alloceren, zodat stack access efficient blijft.

[EfBe]

Paul, het is soms handig (maar ik weet niet of je met je handen aan de database mag zitten, ik heb het vermoeden dat je aan handen en voeten gebonden bent) extra info op te slaan in de database, die at runtime vele minuten kan schelen, maar in theorie wel redundant is.

[Scare360]

EfBe schreef op 07 May 2003 @ 18:28:extra info op te slaan in de database, die at runtime vele minuten kan schelen, maar in theorie wel redundant is.

Ahh, jij bent er zo'een Ik kan me nog goed herinneren dat ik hier pas geleden nog zwaar op tegen was, maar met mangers op de schouders is daar wel een puntje aan te passen.

[EfBe]

paulgielens schreef op 08 May 2003 @ 14:16:
[...]
Ahh, jij bent er zo'een Ik kan me nog goed herinneren dat ik hier pas geleden nog zwaar op tegen was, maar met mangers op de schouders is daar wel een puntje aan te passen.

Precalculation is king waarom na afloop iets gaan bepalen wat je gedurende het proces exact weet