Kezdőoldal » Számítástechnika » Programozás » C# ban a GC.Collect() meghívás...

C# ban a GC.Collect() meghívása milyen esetekben használatos?

Figyelt kérdés

Van értelem egyáltalán,mert ha jól tudom akkor ez csak egy kérés a GC felé de nem biztos,hogy mindent felszabadít majd pont akkor mikor ezt meghívták.


Egy verekedős játéknál pl fontos hogy ne legyen megakadás a GC miatt szóval arra gondoltam hogy minden egyes lefutott harc után amikor a játékosok kiválassza egy pici menüben,hogy remach,vagy character select stb akkor hívnám meg rendszerességgel a GC.Collect() metódust.


Hogy érdemes csinálni?


jún. 16. 17:58
 1/4 anonim ***** válasza:
54%

Attól, mert te kézzel lefuttatod bármikor lefuthat megint amikor a rendszer azt mondja futnia kell. Nem attól lesz akadás, mert lefut a collector, hanem attól, ha nagyon sok szemetet gyártasz és gyakran sok szemetet kell gyűjtenie.


Semmilyen játéknál ne legyen akadás, nincs ez alól kivétel! FPS, stratégiai, logikai......ne legyen!


Unity-zel, vagy milyen motort használsz?


Én direktbe akkor nyomtam collectet, amikor teszteltem a memória használatot és a takarítást. Asseteket töltök be, JS parser engine-t hozok létre, scriptet futtatok stb. Egy AddOn rendszer, UIBuilder funkció amiből a UIBuildert, Asset kezelést én csináltam. Az utóbbi csak ideiglenesen összedobott cucc, azért teszteltem, ha 10x-100x újratöltöm a rendszert (0-ról fájból buildelve), akkor lássam milyen gyorsan takarít, tölt be újra és mennyi szemetet generál, nő e a memória használat.


Alapjáraton az a tanács, hogy ne futtasd, viszont ha olyan műveleteket futtattál ami után SOK-SOK szemét van és mondjuk egy betöltő képernyő végén szeretnél egy cleart, akkor az még beleférhet. Én inkább a szemét generálást próbálom elkerülni. Amit sok videóban nem látok, de lehet én nem ismerem az adott rendszerek poololását azért csinálom máshogy.

jún. 16. 19:03
Hasznos számodra ez a válasz?
 2/4 A kérdező kommentje:

Godot engine ot használok c# al de váltani fogok gdscript re szerintem. Azért választottam a c# ot mert hasonlít szintaxisra a c++ hoz ,viszont c++ t mint script nyelvet a Godot nem támogatja sajnos.

Köszi a segit amúgy adtam zöldet.

jún. 16. 22:53
 3/4 anonim ***** válasza:
100%

A C++ nem script nyelv :)

Én a helyedben megnézném performancia szempontjából melyik a jobb (GDScript, vagy C#) és azt választanám amelyik jobban szerepel.


Én Unity C#, JS (nem Unity-s JS hanem addon rendszerhez JINT engine, mondhatni egy plugin a Unitybe). Még akarok majd LUA-t, mert az állítólag nagyon gyors parser szempontból ami hasznos tud lenni ugye.


A laggspike-okat el tudod kerülni úgy is, ha jó nyelvet választasz és azt JÓL használod! Meg, ha a többszálú dolgokat kellő biztonsággal és szakértelemmel írod meg. Pl generálás, betöltés stb. Sokat tudsz rövidíteni dolgokon. A másik a memóriánál szintén mit tartasz bent. Pl 2 pálya közötti váltásnál az első pályát nem hagyod bent, vagy épp kis pályák esetén, akár a 10 pályát mindet memóriában bent hagyva (mondjuk 10-100MB memóriát foglalva).

jún. 17. 00:38
Hasznos számodra ez a válasz?
 4/4 anonim ***** válasza:
43%
#1 a gc collect eszetlen lassú, milyen nyakatekert hozzáállás az, hogy nem az a lassú, hanem hogy sok szemét gyártasz?? Nyilván lehet optimalizálni, poolokat csinálni, és érdemes is, de működésénél fogva teljesen elkerülhetetlen, hogy a collect() lassú legyen - minden közepes/nagy játéknál elő fog ez jönni, elkerülhetetlenül, ezért nem csinálnak nagy játékot c# alatt(vannak páran akik próbálták, próbálják, mindegyik vagy szarul fut, vagy a játék jellegéből fakadóan újrahasznosítható benne nagyon sok dolog, ezzel elkerülve a kukásautót). Reálisan 1-5 fős fejlesztésig ez a legkisebb problémád, de már ott is tud csücskös lenni.
jún. 18. 10:14
Hasznos számodra ez a válasz?

További kérdések:




Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu

A weboldalon megjelenő anyagok nem minősülnek szerkesztői tartalomnak, előzetes ellenőrzésen nem esnek át, az üzemeltető véleményét nem tükrözik.
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!