[ Ivan Vasić @ 06.10.2003. 23:45 ] @
| Obican programcic za manipulisanje podacima iz access-ove baze jede oko 20MB RAM-a - OK svako pomisli da sam natrpao svasta pa i nije cudo. Onda ja pokrenem CONSOLE application koja cita ono sto ukucam pa to isto ispise na ekran (moze li prostije ???) i takav program pojede 8-9 MB ? Jel ovo normalno ?
Kakav je taj .NET framework ?!?
Da li je ovo uobicajeno ili nesto kod mene ne valja ?!? |
[ Deep|Blue @ 07.10.2003. 00:16 ] @
.net tehnologija se upravo bazira na frameworku.
u totalu ona predstavlja odgovor sun-u na javu i njenu neovisnost o operativnom sistemu.
microsoftov odgovor je .net koji pravi aplikacije u native formatu koji zatim trazi framework da bi se izvrsio
dakle to bi znacilo da nijedna aplikacija ne moze da radi bez frameworka. samim time kad podizes fajl mora da se ukljuci i framework sa svojim alatima.
[ arsa xx @ 07.10.2003. 01:03 ] @
Slicno meni se nesto desilo pa sam odustao od programa koji sam pravio.
Postavlja se pitanje kako prodati program koji zauzima mnogo vise memorije nego sto je to potrebno?
Dobije se lepo radno okruzenje, gotove klase koje stvarno zavrsavaju sve, programeru je stvarno olaksan zivot. Ali krajnji proizvod zaizima mnogo Mb.
[ Deep|Blue @ 07.10.2003. 01:28 ] @
da dobro pitanje.
U biti na poslu imamo 100-mb mrezu, P IV-ke 256 mb rama i sve to fino fercera, medjutim kad odes kod korisnika onda pocinje jeza.
bez obzira na minimal requirements
na IV-kama radi fino
na III-kama radi fino
na II-kama manje zahtevne aplikacija rade manje -vise normalno
Na I-cama i nize aplikacije rade zanimljivo.
uostalom nije sve i do memorije.
imam okorisnika kojem mreza radi na 10mb, ali cini mi se da i to retko kada postize.
znas li kako radi .net aplikacija na PIV u mrezi koja ne moze da dostigne 10 mb protoka
takodjer u zadnjih par godina memorija je postala zbilja jeftina i nije bas kritican problem da aplikacije zauzimaju vise memorije.
bilo bi zanimljivo da jos postoji ogranicenje na 64k
[ Dragi Tata @ 07.10.2003. 06:34 ] @
Da, .NET baš kao i Java "urniše" memoriju i zato je u principu daleko pogodniji za Web aplikacije nego za desktop. Ovo će možda da se promeni kad izađe Longhorn, koji bi trebalo da ima .NET Framework ugrađen "dublje" u OS i potpuno novu GUI biblioteku "Avalon".
[ Ivan Vasić @ 07.10.2003. 18:29 ] @
Sve je to lepo ali koliko vidim ispada da ili cekamo taj Longhorn ili da pisemo aplikacije u .NET a da ih koristimo za koju godinu sa vise memorije :(
[ Dragi Tata @ 07.10.2003. 19:06 ] @
Hehe, sve zavisi od hardvera. Na mojoj kućnoj mašini (Athlon 2000+ i 512Mb RAM) .NET aplikacije rade pristojno. Na poslu (PIII 733MHz i 256Mb RAM) mnogo slabije.
[ Ivan Vasić @ 07.10.2003. 23:11 ] @
E pa i ja imam pristojnu konfiguraciju (Athlon 1Ghz, 384 RAM) i to radi OK u pocetnim fazama razvijanja aplikacije. Ali sto vise se udubljujem u pisanje nekako sve gore i gore se ponasa  )) cudno a ?  ))
E a najvise me nervira kad recimo otvorim novu formu u programu preko neke ispod pa je onda zatvorim i onda se desava "iscrtavanje" ove forme koja je bila ispod .... katastrofa.... da ne pricam sto se isto desava i ako ima context menu pa svaki put kad kliknem desnim ista stvar ... uf uf  (
Dok recimo sa DirectX-om i nema toliko problema. On jede pa jede nema sta ali se bar pristojno ponasa i rendering i sve ostalo.
MOJE LICNO MISLJENJE :
Mozda cu sad da lupim glupost - molim bez smeha 
Kolko sam upucen .NET koristi neku vrstu GUI+ (ili GDI nemojte da mi verujete) ili tako nesto ne znam kako se zove i plus valjda obican GUI. Imam jedno fino programce koje mi pokazuje koje dll-ove moj program koristi i manipulise njima.Tako sam ja jednom iskljucio taj GUI+ i program je drasticno bolje radio ali BEZ ikakvih smetnji. GUI+ suvisan ?
[ degojs @ 08.10.2003. 00:21 ] @
Treba imati na umu ono što reče DT - da je .NET, bar u prvo vreme, namenjen server-side programiranju. Kasnije, videćemo.
Što se tiče usporenja, ako je vezano za rad u Visual Studiju, stvari značajno bolje stoje u novijoj verziji, 2003 (posebno pri radu sa većim projektima u VB - pozadinsko kompajliranje više ne usporava rad onoliko kao pre).
[ Shadowed @ 08.10.2003. 00:25 ] @
Offtopic:
Pa jel taj VS2003 izasao ili je jos beta?
[ degojs @ 08.10.2003. 01:01 ] @
Izašao brale davnih dana. I većina sitnica koje su bile nedorađene u 2002 su sređene plus svašta još :)
[ Shadowed @ 08.10.2003. 01:10 ] @
Do djavola. Pomesao sam sa Office-om. On izlazi krajem oktobra...
Gde li cu da ga nadjem samo u ovo doba izumiranja ulicne piraterije :)...
[ Ivan Vasić @ 08.10.2003. 11:07 ] @
Kad smo vec kod toga VS 2003 ima dosta poboljsanja u odnosu na 2002
ali ja nigde ne mogu da ga nadjem. Ajd ako neko ima ili zna gde ima nek
javi na
[email protected]
Thnx
[ dusans @ 08.10.2003. 14:09 ] @
Ne znam zašto niko nije uporedio realan primer sa zauzećem memorije? Onako kako se vidi između dva data primera ispada da linija koda jede recimo pola mega rama što je čist promašaj u proračunu! Naime pri izvršavanju .NET aplikacije u memoriju se učitavaju sklopovi na koje se referencira i koje poziva izvršni kod, npr. System, System.Drawing, ... pa prema tome da li imao jednu liniju koda ili hiljadu linija uvek će ti učitavati sklopove i prema tome za tu svrhu pojesti desetak ili više mega rama!
Iz iskustva govorim da poslovna aplikacija na kojoj radim i čiji je .exe fajl oko 7 mega i sadrži preko dvesto hiljada linija koda posle intenzivnog rada ne pređe više od nekih tridesetak mega rama!
[ Dragi Tata @ 08.10.2003. 19:10 ] @
Ne zavisi potrošnja memorije toliko od broja linija koda, već od broja i veličine objekata koje napraviš. Ako recimo radiš sa relativno konstantnim brojem objekata, ili ih "recikliraš", onda je moguće potrošnju memorije držati pod kontrolom.
Ako stvarno poveruješ da će GC da te oslobodi svih briga oko memorije pa kreneš da proizvodiš nove objekte na veliko, onda samo gledaj Task Manager i čudi se...
[ Ivan Vasić @ 08.10.2003. 20:08 ] @
Ok. Znaci napraviti objekat i onda uraditi Dispose() i nema ga vise u memoriji.
Sta onda sa objektima koji ne mogu da se Dispose-uju ??? (Recimo upotrebi neki Int i to neki veliki broj i ne mozes da uradis X.Dispose(), pa jos recimo da pozivas proceduru vise puta....)
I jos jedno pitanje : Da li ima veze ako referenciram neke objekte (ciljam na using System, using System.Drawing ...) a ne koristim ih ? Jel zauzimaju mem ?
[ Dragi Tata @ 08.10.2003. 20:21 ] @
Citat: ivan@elfak:
Ok. Znaci napraviti objekat i onda uraditi Dispose() i nema ga vise u memoriji.
Ne!!! Dispose uopšte ne briše objekat iz memorije. Koliko znam, nema načina da eksplicitno izbrišeš pojedine objekte. Sa druge strane, možeš da eksplicitno pozoveš GC.Collect koja će da počisti GC heap od zaostalih objekata ako zaključiš da ti aplikacija zauzima previše memorije. Pogledaj malo dokumentaciju za GC klasu.
Citat: ivan@elfak:
I jos jedno pitanje : Da li ima veze ako referenciram neke objekte (ciljam na using System, using System.Drawing ...) a ne koristim ih ? Jel zauzimaju mem ?
Objekat zauzme memoriju samo ako ga eksplicitno stvoriš sa new. Međutim, ako učitaš neke dll-ove (referenciraš ih) i oni će naravno da zauzmu memoriju, ali je ta memorija konstantna.
[ arsa xx @ 09.10.2003. 09:34 ] @
Znaci .NET nije bas pogodan za male desktop aplikacije!?
A pogodan je za serverside (ASP .NET) pretpostavljam i za web servise??
[ ace @ 09.10.2003. 11:02 ] @
ne znam da li je neko vec pomenuo ali da li si pokusao taj program minimiziras pa maksimiziras pa potom pogledas u listi procesa koliko zauzima memorije.
to ne zauzima program vec gc. koliko program stvarno zauzima videt ces posle minimiziranja i maksimiziranja kada gc odradi posao.
sa dolaskom generica stvar ce se uveliko popraviti. nazalost ne verujem da je to slucaj i kod jave jer kod nje generici nisu predvidjeni u core-u vec ce biti vise sminka i jedna lepa tehnika kodiranja.
[ dostanov @ 09.10.2003. 19:58 ] @
Citat: ace:
koliko program stvarno zauzima videt ces posle minimiziranja i maksimiziranja kada gc odradi posao.
Vaoo, za ovu foru nisam znao!
Kod mene su u jednom trenutku (na WinXP-u) bili pokrenuti VS.Net 2003, Acrobat Reader 5 i Opera 7. Posle operacije minimiziranje - maksimiziranje prozora, zauzece memorije se drasticno popravilo (btw. ja imam 256 MB RAM-a):
VS.Net sa 60 MB na 14 MB
A.Reader sa 64 MB na 4 MB !!!!!
Opera sa 33 MB na 17 MB
Ceo sistem je malo zivnuo, narocito VS.Net. Sve su ovo Win32 aplikacije, tako da mogu samo da zamislim koliko bi se popravilo stanje kod .Net aplikacija.
[ Dragi Tata @ 09.10.2003. 20:04 ] @
Hmmm, nisam siguran da minimiziranje i maksimiziranje obavezno pokreće GC. Ono što se tada desi je da sistem prebaci deo zauzete virtuelne memorije iz RAM-a na HDD.
[ ace @ 12.10.2003. 01:52 ] @
zar virtuelna memorija nije ona na hdd.
tacno za gcc. hteo sam napisati optimizacija.
hteo sam poentirati da je prava velicina
net programa ona koja pise u procesu
posle minimiziranja i maksimiziranja.
onaj veliki deo koji nestane je memorija
potrebna za funkcionisanje gc-a.
[ mbran @ 27.07.2004. 00:06 ] @
Vidim da su vasa iskustva sa .Net-om na slabijim masinama losa, ali moram da izlozim svoj slucaj. Napravio sam aplikaciju koja koristi .Net Remote-ing, Sto znaci da mi je Interface bio na jednom kopjuteru koji je inace P1 166Mhz, a aplikativni server i baza na drugom kompu, povezani obicnim ukrstenim mreznim kablom, i to je funkcionisalo savrseno. Samo prvi put kada se staruje deo aplikacije na P1, potrebno mu je da izvuce neke podatke iz baze oko 1s, posle toga svaki pristup bazi tj. povlacenje podataka i update je radio skoro trenutno.
[ ace @ 27.07.2004. 01:12 ] @
ovo je interesantan kod:
Code: using System;
namespace FinalizeBenchmark {
class Benchmark {
/// <summary>
/// Start with an arg to perform the Dispose benchmark. Start with no args for a no dispose benchmark.
/// </summary>
static void Main(string[] args) {
// Get everything jitted
DateTime x = DateTime.Now;
FinalizeObject o = new FinalizeObject();
o.DoSomeWork();
o.Dispose();
o = new FinalizeObject();
// Collect and wait
GC.Collect();
GC.WaitForPendingFinalizers();
// Benchmark
if (args.Length != 0) {
performBenchmarkDispose();
} else {
performBenchmarkNoDispose();
}
}
static void performBenchmarkNoDispose() {
DateTime start, end;
start = DateTime.Now;
for (int i = 0; i < 10000000; i++) {
FinalizeObject o = new FinalizeObject();
o.DoSomeWork();
}
GC.Collect();
GC.WaitForPendingFinalizers();
end = DateTime.Now;
Console.WriteLine("No dispose time: {0}", end - start);
}
static void performBenchmarkDispose() {
DateTime start, end;
start = DateTime.Now;
for (int i = 0; i < 10000000; i++) {
FinalizeObject o = new FinalizeObject();
o.DoSomeWork();
o.Dispose();
}
GC.Collect();
GC.WaitForPendingFinalizers();
end = DateTime.Now;
Console.WriteLine("Dispose time: {0}", end - start);
}
}
class FinalizeObject : IDisposable {
private volatile int someInt;
private static Random random = new Random();
public void DoSomeWork() {
this.someInt = random.Next(10000000);
}
private bool disposed = false;
public void Dispose() {
Dispose(true);
GC.SuppressFinalize(this);
}
protected void Dispose(bool disposing) {
if (disposed) return;
disposed = true;
if (disposing) {
// Dispose Managed resources
// Not needed in this class, but we could have a reference to
// a managed object that has an unmanaged resource
}
// Unmanaged resources
// Here we would get rid of direct unmanaged resources
}
~FinalizeObject() {
Dispose(false);
}
}
}
[ safran @ 28.07.2004. 01:44 ] @
resio sam ovaj problem sa memorijom
ukrao sam sam exe iz systemmehanic-a
koji prazni ram
tako da je zauzimao sam 15Mb RAM-a
Copyright (C) 2001-2025 by www.elitesecurity.org. All rights reserved.
|