Citat:
Evo bas gledam TaskManager da vidim koliko trenutno trosim rama ... oko 100 MB (5-6 userland aplikacija ukljucujuci Operu koja je zauzala 80 MB)
40-50 MB rama za jednostavnu igru ... mnogo
E onda tu igricu treba praviti u C++-u gde mozes da ostvaris direktnu kontrolu nad working set-om, u .NET ne mozes direktno iz managed code-a. A inace to sto vidis iz task manager-a je slaba indikacija potrosnje memorije posto je to ceo working set (ako nemas vistu a po potpisu mi deluje da nemas) koji ukljucuje i shared working set (npr adresni prostor u koji je ucitan user32.dll je deljen), pravo zauzece je zapravo private working set, a to je vrednost koju ne mozes da dobijes kroz task manager, treba ti npr sysinternals process explorer, pa kad ti on pokaze koliko u stvari imas skrivenih procesa i koliki su working setovi videces da 40-50 MB zaista ne cini nikakvu razliku, sve i da zauzece jeste 40-50Mb a nije zbog nacina na koji .NET barata memorijom.
A sad, njegova velika slika ima tacno 12.5Mb sirovih podataka, toliko ce imati i zbir 52 karte koje isece iz velike slike ili ucita pojedinacno, te slike ne mogu da lebde negde izmedju IO-a i memorije ili su ucitane ili nisu i ako disposujes veliku sliku nakon isecanja memory footprint MORA da bude isti, jedino sto si vise koristio file IO i/ili dekoder overhead da ucitas pojedinacne karte. Ali sve to je nevazno u poredjenju ova dva pristupa zato sto se oba svode na O(1) algoritam i desavaju se samo jednom na pocetku aplikacije.
Jedini nacin da sprecis uvecanje private working set-a je da ili ne koristis hidef hicolor slike i smanjis footprint ili da ucitavas sliku po sliku on demand i da ih po upotrebi dealociras, sto je veoma lose resenje jer minimum moras u GDI-u da drzis zive handlove za one karte koje se vide na radnoj povrsini, da ne pominjem udar na performanse jer bi zapravo stedeo na jeftinom resursu (memorija) tako sto bi koristio skup resurs (file IO) cija upotreba je sad po algoritmu koji je sigurno veci od O(1).
Ja ne znam zasto se ljudi toliko naprezu oko ovh memorijskih "problema" sa .NETom i kao indikator stalno pominju task manager. .NET ce uzeti memorije koliko mu treba da formira optimalni working set i dok god na sistemu ima dovoljno RAM-a NECE vratiti memoriju OS-u, sta vise kad ima bas puno RAM-a verovatno se ni Gen2/LOH collect nece desiti nikad (zbog cega je vazno disposeovati disposable objekte) i samim tim ce Gen2 objekti sa GDI handlovima drzati i unmanaged heap zakljucan jer OS nema potrebe da shrinkuje aktivne procese (sto bi uteralo .NT proces u Gen2 collect i finalizaciju mrtvih Gen2 objekata). Ako bas hoces da vidis kako izgleda barebone working set za tvoju aplikaciju pokreni neki memory compressor i shrinkuj proces i za .NET aplikacije u idle rezimu ces videti drasticno smanjenje. Ali ces onda videti i drasticno usporenje kad .NET krene da ponovo alocira svoj optimalni working set kad krenes da koristis aplikaciju.
Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan, sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv… - Z.Đinđić
Učitavanje slike i veliko zauzeće memorije
