.Net = ramvreter

[Verwijderd]

jongens ligt het nu aan mij of is die.net echt een ramvreter?

ik heb simpel progje gemaakt(zoiets als winbar) in C# , bestaat uit 3 frames, en als die draait is er toch meer dan 20mb ram weg. .NET framework zuigt al ongeveer 8mb. en 2e probleem is dat het progje alleen bij mij werkt, ik heb het bij 2 vrienden geprobeerd en wil niet werken.(jaja ik heb wel framework geinstalleerd op andere pcs) maar je krijgt constant van die vage errors , terwijl het op mijn pc perfect draait. ik heb dus niet zon goede indruk van .NET gedoe, of ik had misschien te hoge verwachtingen

[WOmBaT]

Heb je ook de update van het .net framework gedownload en geinstalleerd op die andere pc's? En over je eerste vraag; ja, .NET is een flinke ramvreter.

[Verwijderd]

maar je krijgt constant van die vage errors

Wil je nog delen met ons welke errors? of zeg je van nah ik wil alleen even klagen ik heb geen hulp nodig verder?

[Verwijderd]

.net vreet wat meer ram. Big deal. Een 'spelletje' als Unreal Tournament vreet ook 128MB ram, terwijl dat nergens voor nodig is. Ligt ook geen hond wakker van.

[Gerco]

Je draait meestal ook maar 1 Unreal Tournament tegelijk. Als je 5 .NET apps tegelijk draait (en je weet heus wel dat er veel mensen met meer dan 5 apps tegelijk open zitten), zit je al op minimaal 8 + 12 * 5 = 68MB. En dan heb ik het nog niet over .NET apps die zelf ook flink wat geheugen in gebruik hebben, maar kleine apps zoals die van de topicstarter.

PC's krijgen tegenwoordig steeds meer RAM, maar als MS wil dat alle Windows Apps .NET apps worden, mogen ze wel wat aan het geheugengebruik doen, OF RAM gaan sponsoren.

[roelio]

Verwijderd schreef op 18 augustus 2002 @ 10:51:
... Een 'spelletje' als Unreal Tournament vreet ook 128MB ram, terwijl dat nergens voor nodig is. Ligt ook geen hond wakker van.

en waarom is dat nergens voor nodig ... als alles van de schijf geladen moet worden heb je immers veel te lage framerates etc.

[Wouter Tinus]

limoentje schreef op 18 augustus 2002 @ 11:00:
[...]
en waarom is dat nergens voor nodig ... als alles van de schijf geladen moet worden heb je immers veel te lage framerates etc.

Juist, net als de performance van een .NET app omlaag gaat als alle libraries van de schijf geladen moeten worden.

[Gerco]

limoentje schreef op 18 augustus 2002 @ 11:00:
[...]
en waarom is dat nergens voor nodig ... als alles van de schijf geladen moet worden heb je immers veel te lage framerates etc.

Of het nodig is is niet de vraag. Dat .NET zoveel geheugen gebruikt zal (in ieder geval nu) vast wel nodig zijn. Het gaat meer om de "intended use" van de boel. Spelletjes gebruiken VEEEEL geheugen, vaak zoveel als ze kunnen krijgen, maar daar is het de bedoeling dat er maar 1 tegelijk draait. Als de filosofie van MS doorgaat willen ze dat ALLE Windows apps op .NET gaan draaien. Dan zouden dus ALLE apps minimaal 10MB gebruiken (ex. Framework, die 8MB valt dan in het niet).

Is het de bedoeling dat alle apps .NET worden? Of heb ik dat verkeerd begrepen van de marketing jongens? Ik weet nog steeds niet wat nou eigenlijk de hele bedoeling is van dat .NET.

[roelio]

Gerco schreef op 18 augustus 2002 @ 11:03:[...]
Of het nodig is is niet de vraag.
...

Dat was wel Otis' opmerking waar ik op reageerde.

[Verwijderd]

limoentje schreef op 18 augustus 2002 @ 11:00:
[...]
en waarom is dat nergens voor nodig ... als alles van de schijf geladen moet worden heb je immers veel te lage framerates etc.

Het is erg veel hoor, 128MB ram voor wat textures. Maar niemand vindt dat raar. Men vindt het WEL raar als een complete virtual machine met jitcompiler en cache(!) wordt geladen voor het runnen van een programma, en dat vreet dan 20MB. Nou poehee.

Overigens is het niet zo dat per instance je 20MB kwijt bent. Zou niet best zijn zeg, dat je op een webserver met ASP.NET je bij de 30e visitor je 512MB rambank vol zit.

ANyway, deze rant gaat nergens over. de topicstarter klaagt ergens over, snapt niet wat de reden ervoor is en is kennelijk bang dat zn 512MB ram vuil wordt van het gebruik. Wie weet alloceert ZIJN programma wel 10 arrays van 1MB groot, weten wij veel.

[Verwijderd]

Gerco schreef op 18 augustus 2002 @ 10:54:
Je draait meestal ook maar 1 Unreal Tournament tegelijk. Als je 5 .NET apps tegelijk draait (en je weet heus wel dat er veel mensen met meer dan 5 apps tegelijk open zitten), zit je al op minimaal 8 + 12 * 5 = 68MB. En dan heb ik het nog niet over .NET apps die zelf ook flink wat geheugen in gebruik hebben, maar kleine apps zoals die van de topicstarter.

Volledig uit de lucht gegrepen kolder. Dus bij 5 users heb ik een 68MB memory usage? En bij 100 users dus 8 + 12*100 = 1208MB... aiii!! dat gaat niet passen!

Get a grip. KLagen over memory usage is prima, maar kom dan ook met een programma waarbij de sourcecode bekend is en dus geen massa-allocaties en andere PRUTCODE in zitten verwerkt.

[Prozaq]

Je hebt echt geen mega allocaties nodig, een simpel progje met een formpje en een knopje is genoeg voor wat, 10 mb geheugengebruik ofzo? En een programma als unreal doet toch echt even iets meer dan een hello world progje.

[Gerco]

Verwijderd schreef op 18 augustus 2002 @ 12:41:
Get a grip. KLagen over memory usage is prima, maar kom dan ook met een programma waarbij de sourcecode bekend is en dus geen massa-allocaties en andere PRUTCODE in zitten verwerkt.

Wat is er hier nu volledig uit de lucht gegrepen kolder? Ik snap dat je pro .NET bent, maar om nu gelijk te roepen dat zijn programma wel prut MOET zijn en dat het onnodig veel memory alloceert alleen maar omdat JIJ VIND dat hij onzin uit zit te kramen gaat wel een beetje ver he?

Let wel: ik geef je geen ongelijk, zijn programma zou best prutcode kunnen bevatten, maar ik geef de topicstarter het voordeel van de twijfel. Ik neem aan dat als hij zegt dat het een simpel prog is, dat dat het ook IS.

[Jake]

Prozaq schreef op 18 augustus 2002 @ 13:08:
Je hebt echt geen mega allocaties nodig, een simpel progje met een formpje en een knopje is genoeg voor wat, 10 mb geheugengebruik ofzo? En een programma als unreal doet toch echt even iets meer dan een hello world progje.

Ja, dat is misschien wel zo, maar het is veel belangrijker wat 1000 keer dat simpele proggie doet.

Stel je hebt simpel proggie 1 MB: 1000 keer moet ie 1000 MB

Of je hebt .NET is 10 MB bij 1 keer, en bijv maar 100 MB bij 1000 keer (omdat al het dubbele gedeeld wordt).

Ik zeg niet dat het zo is, het is een voorbeeld, maar om met nou meteen over het geheugen gebruik van 1 instantie van iets te zeuren (het is sowieso een brak gemaakt, want werkt alleen op PC van topic-starter).

[Verwijderd]

LLBLGen, mn data-access tier generator, geschreven in C#, grote GUI, veel interne structuren, gebruikt 16MB. Start ik een kleine prut console app op (debugbuild of release build), 2MB slechts. Minimize ik LLBLGen met zn zware gui, is het slechts 440KB. Minimize ik de console app, is hij nog slechts 96KB in memory.

Moet ik nog toelichten waar dan de memory voor gebruikt wordt, of kun je dat zelf uitdokteren? (hint: caching structuren voor gui elements)

Aan de mensen die maar wat roepen: doe eens een test voordat je gilt. Helpt de 'discussie' wat meer en laat hem niet verzanden in welles-nietes geblaat.

[Verwijderd]

Jake: 1000 keer hetzelfde process opstarten zal 1000 keer een apart application domain opzetten wat tot gevolg heeft dat je 1000 keer de CLR in je memory hebt, althans de resultaten van de JIT. Wil je echter code sharen vanuit 1 app domain, dan gebruik je een andere techniek, nl. 1 hosting applicatie die de application domains eventueel creeert of anders objects / threads binnen dezelfde application domain, wat resulteert in 1 CLR instance. (Iets wat asp.net bv ook doet)

[mbravenboer]

Ik amuseer mezelf uitstekend in dit topic. Absoluut niet vanwege het onderwerp of het probleem, maar voornamelijk omdat het boeiend is om te zien hoe er op dergelijke topics wordt gereageerd door 'voorstanders' of 'tegenstanders' van een platform/taal/idee.

Het blijkt namelijk dat de grens tussen een bagatelliserende en probleem-erkennede reactie niet zozeer ligt bij de ernst van het probleem zelf, maar voornamelijk bij het gevoel wat de reageerder bij een platform heeft. Is dit gevoel positief, dan worden problemen of opmerkingen al snel als irrelevant afgehandeld (in niet al te respectvolle bewoordingen zelfs), is het gevoel bij een platform negatief, dan wordt alles uit de kast gehaald om het probleem te onderschrijven.

Ik maak me hier zelf ook vaak schuldig aan, dus trek je het niet aan, maar grappig is het wel .

[Verwijderd]

Interessant artikel over het geheugen gebruik in .Net.

[ Voor 0% gewijzigd door Verwijderd op 18-08-2002 13:33 . Reden: Link toegevoegd ]

[Aetje]

Verwijderd schreef op 18 augustus 2002 @ 10:51:
.net vreet wat meer ram. Big deal. Een 'spelletje' als Unreal Tournament vreet ook 128MB ram, terwijl dat nergens voor nodig is. Ligt ook geen hond wakker van.

URT wordt dan ook niet in een professionele serveromgeving als OS/framework gebruikt...

[Jake]

Otis: mijn voorbeeld was niet bedoeld als kloppende waarden oid, maar alleen om aan te geven dat het eigenlijk niet interessant is hoeveel memory een single user/single instance van een proggie gebruikt (of het nog 1 of 10 MB is). Wat wel interessant is hoeveel het gebruik bij meerdere users/instanties is.

Je leest wel vaker op GoT: zus-en-zo gebruikt 20 MB; wat een resource-hog. Maar ze vergeten erbij te zeggen dat ze op dat moment 256MB+ vrij hadden (en Windows toch iets met dat geheugen moet doen).

Wat ik dus bedoelde: kijk alleen naar memory-use op het moment dat je memory 'op' raakt (bijvoorbeeld door veel te veel tegelijk te draaien), dan krijg je een goed beeld van hoeveel iets echt gebruikt. Daarna kan je proberen het te verminderen.

[Verwijderd]

ik wil de source best met jullie delen, en er zal vast wat prutcode in zitten
zal het straks effe online zetten,

was ook mijn eerste poging in C#

maar zon zooitje is het echter niet, gezien ik enige java ervaring heb

[Verwijderd]

mbravenboer schreef op 18 augustus 2002 @ 13:28:
Ik amuseer mezelf uitstekend in dit topic. Absoluut niet vanwege het onderwerp of het probleem, maar voornamelijk omdat het boeiend is om te zien hoe er op dergelijke topics wordt gereageerd door 'voorstanders' of 'tegenstanders' van een platform/taal/idee.
Het blijkt namelijk dat de grens tussen een bagatelliserende en probleem-erkennede reactie niet zozeer ligt bij de ernst van het probleem zelf, maar voornamelijk bij het gevoel wat de reageerder bij een platform heeft. Is dit gevoel positief, dan worden problemen of opmerkingen al snel als irrelevant afgehandeld (in niet al te respectvolle bewoordingen zelfs), is het gevoel bij een platform negatief, dan wordt alles uit de kast gehaald om het probleem te onderschrijven.

Klopt Maar daarom is het nog wel zo dat een claim die niet terecht is, best met een grasmaaier bewerkt mag worden, omdat die claim volledig verzonnen is en niet getest is door even in de taskmanager te kijken

[Gerco]

In neem aan dat hij niet 12 MB per instantie alloceert als je 100x hetzelfde programma start. Voor zover ik weet worden codepages gewoon geshared tussen meerdere instnties van 1 proces. Alleen de data pages zijn per proces, wat ook logisch is. Dus als je 100 keer hetzelfde prog start zal je heus geen ram problemen tegenkomen. Waar IK me me zorgen over maak is 10 of 20 VERSCHILLENDE programma's Die hebben allemaal verschillende codepages en dus worden die allemaal in het geheugen gezet. De CLR wordt hopelijk gedeeld tussen al die apps (hmm, blijkbaar niet, maar goed Java doet dat ook niet, zal vast moeilijk zijn om te doen).

We hebben allemaal een volle systray, als dat allemaal geheugen-vretende apps zouden zijn, gebeurde er niet veel meer op je PC, iig niet snel.

[Verwijderd]

Jake schreef op 18 augustus 2002 @ 13:37:
Otis: mijn voorbeeld was niet bedoeld als kloppende waarden oid, maar alleen om aan te geven dat het eigenlijk niet interessant is hoeveel memory een single user/single instance van een proggie gebruikt (of het nog 1 of 10 MB is). Wat wel interessant is hoeveel het gebruik bij meerdere users/instanties is.
Je leest wel vaker op GoT: zus-en-zo gebruikt 20 MB; wat een resource-hog. Maar ze vergeten erbij te zeggen dat ze op dat moment 256MB+ vrij hadden (en Windows toch iets met dat geheugen moet doen).

Precies. IIS5's DllHost processes nemen ook telkens meer ram, het lijkt net een memory leak. Dat is het echter niet, maar door de cacheinstellingen neemt het process gewoon meer vrije memory voor caching, het is immers vrij en het mag volgens de instellingen

Nu zijn claims van 20MB al onzin, maar men gaat die ene waarde meteen extrapoleren over 100 instances. 100 keer word opstarten met een grote doc is ook 100 keer veel memory kwijt. 100 users servicen is voor asp.net echter geen resource hog, sterker, die vreet minder memory dan DllHost op den duur .

Wat ik dus bedoelde: kijk alleen naar memory-use op het moment dat je memory 'op' raakt (bijvoorbeeld door veel te veel tegelijk te draaien), dan krijg je een goed beeld van hoeveel iets echt gebruikt. Daarna kan je proberen het te verminderen.

Nou, toch wil ik dit wel graag vooraf weten . Toen ik net 2 dagen met .NET bezig was (nog met de beta van vs.net ) en mn 384MB memory vol raakte, vroeg ik me wel even af waar dit naartoe moest. Echter nu is alles gewoon wel op orde, alleen vreet VS.NET in debugmode soms nog wel extravagant veel mem, maar het zal wel nodig zijn en het is beschikbaar, dus who carez. Maar extrapolatie van de memusage van een client applicatie met zware gui naar het gebruik van een guiless app als een webservice in ASP.NET is niet correct.

[Verwijderd]

Gerco schreef op 18 augustus 2002 @ 13:45:
In neem aan dat hij niet 12 MB per instantie alloceert als je 100x hetzelfde programma start. Voor zover ik weet worden codepages gewoon geshared tussen meerdere instnties van 1 proces. Alleen de data pages zijn per proces, wat ook logisch is. Dus als je 100 keer hetzelfde prog start zal je heus geen ram problemen tegenkomen.

Ik start ff 10 keer LLBLGen op, ze hebben allemaal 16MB mem in use. Dit komt door de totaal van elkaar afgeschermde application domains. Het is heel secure, maar ja daar betaal je dan wel een prijs voor.

Waar IK me me zorgen over maak is 10 of 20 VERSCHILLENDE programma's Die hebben allemaal verschillende codepages en dus worden die allemaal in het geheugen gezet. De CLR wordt hopelijk gedeeld tussen al die apps (hmm, blijkbaar niet, maar goed Java doet dat ook niet, zal vast moeilijk zijn om te doen).

Nu is de CLR nog buiten het OS geplaatst. Ik heb geen idee hoe dit in de toekomst zal veranderen, maar veel memory zal nodig blijven, door de appdomains.

[ACM]

Verwijderd schreef op 18 augustus 2002 @ 13:42:
Klopt Maar daarom is het nog wel zo dat een claim die niet terecht is, best met een grasmaaier bewerkt mag worden, omdat die claim volledig verzonnen is en niet getest is door even in de taskmanager te kijken

Neemt niet weg dat mensen graag met een beetje respect en vertrouwen worden behandeld

[Gerco]

Verwijderd schreef op 18 augustus 2002 @ 13:48:
Maar extrapolatie van de memusage van een client applicatie met zware gui naar het gebruik van een guiless app als een webservice in ASP.NET is niet correct.

Daar heb je 100% gelijk in, maar de enige die het woord ASP genoemd heeft in dit topic ben jij. Er trok niemand een vergelijking tussen een GUI app en een ASP.NET page of webservice of wat voor soort non-GUI app dan ook.

[Gerco]

Verwijderd schreef op 18 augustus 2002 @ 13:52:
Nu is de CLR nog buiten het OS geplaatst. Ik heb geen idee hoe dit in de toekomst zal veranderen, maar veel memory zal nodig blijven, door de appdomains.

Misschien gaat dat net zoiets als IE worden. Bijna alles zit al in het OS op het moment van opstarten, dus elke losse instantie van de CLR (of IE) nemen bijna geen RAM meer in beslag.

[Verwijderd]

jongens kijk hiernaar , als je hem 10x opstart dan gebruikt ie nog steeds ongeveer 20mb, dit is wel vaag, zal later de source effe posten, kijken of het aan mij ligt

http://www26.brinkster.com/bestdeal/blaat.gif

[Prozaq]

Ik start ff 10 keer LLBLGen op, ze hebben allemaal 16MB mem in use. Dit komt door de totaal van elkaar afgeschermde application domains. Het is heel secure, maar ja daar betaal je dan wel een prijs voor.

Je doet net alsof dit een nieuw concept is. Op deze manier kun je alles wel goedpraten.

[Prozaq]

Verwijderd schreef op 18 augustus 2002 @ 14:38:
jongens kijk hiernaar , als je hem 10x opstart dan gebruikt ie nog steeds ongeveer 20mb, dit is wel vaag, zal later de source effe posten, kijken of het aan mij ligt

http://www26.brinkster.com/bestdeal/blaat.gif

[afbeelding]

Werkt niet

[Verwijderd]

Prozaq schreef op 18 augustus 2002 @ 14:40:
[...]


Werkt niet

hmm , vaag ook niet als je link copy paste in IE?

[Vorkie]

Vergeet ook niet dat hij pas is RC1 status is hé dus de buggies moeten er nog uitgehaalt worden


maar ja, hij eet mijn ram op, maar errors krijg ik niet

HTTP1.1 STATUS 403 Remote Access to this object forbidden This file cannot be directly accessed from a remote site, but must be linked through the Brinkster Member's site.

en vergeet ook niet, tegenwoordig heeft iedereen wel meer of gelijk aan 256Mb ram, en dat mag van mij gebruikt worden, het is een server, geen workstation

[Verwijderd]

heb je het over mijn progje? draait ie wel bij jou dan?

[Verwijderd]

foutje!

[LordLarry]

Verwijderd schreef op 18 augustus 2002 @ 14:38:
jongens kijk hiernaar , als je hem 10x opstart dan gebruikt ie nog steeds ongeveer 20mb, dit is wel vaag, zal later de source effe posten, kijken of het aan mij ligt

Erm....ik denk dat een aantal mensen hier even een opfris cursus kunne gebruiken over (Windows) geheugen beheer

Windows is niet gek, die laad niet 10x je programma in het geheugen! De code is altijd hetzelfde, dus daar houd ie maar 1 instantie van in het geheugen.

Verder laad Windows zoveel mogelijk in het geheugen als het kan, want RAM is sneller als je HDD.

.Net kan best 20Mb aan geheugen opvreten, geen idee, maar dat doet ie maar 1x. Maakt niet uit hoeveel .Net programma's je draaid.

Als laatste wil ik nogmaals wel even vertellen dat je niet in de taskmanager bij Mem Usage moet kijken over hoeveel geheugen een programma gebruikt, maar bij VM Size. Bkijken de Mem Usage maar eens voor en nadat je een programma geminimaliseerd hebt.

[Gerco]

LordLarry schreef op 18 augustus 2002 @ 16:17:
Windows is niet gek, die laad niet 10x je programma in het geheugen! De code is altijd hetzelfde, dus daar houd ie maar 1 instantie van in het geheugen.

Dat zei ik net ook, maar Otis ontkrachtte dat door te zeggen dat ze allemaal een ander Application Domain hebben. Ik heb daar nog nooit van gehoord, dus ik neem maar aan dat hij weet waar 'ie het over heeft.

[LordLarry]

Ik moet zeggen dat ik er ook nog nooit van gehoord hebben, dus ik zou het mis kunnen hebben. Maar ik betwijfel het

Is daar een url over?

[Verwijderd]

ACM schreef op 18 augustus 2002 @ 13:52:

[...]

Neemt niet weg dat mensen graag met een beetje respect en vertrouwen worden behandeld

No offence, maar ik behandel iemand die zonder te checken uit zn bolle hoofd gaat raaskallen dat app ABC een X amount ram gebruikt en dat dat schandalig is echt met 0.0 respect.

[Verwijderd]

LordLarry schreef op 18 augustus 2002 @ 17:18:
Ik moet zeggen dat ik er ook nog nooit van gehoord hebben, dus ik zou het mis kunnen hebben. Maar ik betwijfel het

Is daar een url over?

Je weet niet wat een application domain is? Wellicht wordt het dan tijd eens in .NET te duiken.

Over tegelijk opstarten:
hier een aantal versies opgestart, allemaal open, dus niet geminimized. (Ik heb even geknipt horizontaal ivm de grootte van het plaatje)


en nu allemaal geminimized:


1 instance is wat groter, dat is op zich wel vaag. Wat ook vaag was, is dat wanneer je ze collectief minimized (dus met die button op de quicklaunch bar) ze 16MB aan memory blijven houden, maar wanneer je dedicated op de minimize button klikt ze wel alle gui mem vrijgeven (ik heb dat niet ingebakken, dus dat is framework crap).

Anyway: memusage bij meerdere keren opstarten is per instance dus gewoon oplopend, en bij minimized guis dus marginaal per instance. taskbar programma's hebben geen guis dus ik betwijfel of dit op den duur veel ellende oplevert. Want als je 20 applicaties OPEN hebt, dus non minimized, ben je aardig druk bezig en heb je ook nu al veel mem nodig.

[ACM]

Verwijderd schreef op 18 augustus 2002 @ 17:29:
No offence, maar ik behandel iemand die zonder te checken uit zn bolle hoofd gaat raaskallen dat app ABC een X amount ram gebruikt en dat dat schandalig is echt met 0.0 respect.

Waarom?

Wijs die persoon erop (beargumenteerd natuurlijk) dat ie het fout heeft en als ie _dan_ blijft beweren dat ie gelijk heeft kan je altijd nog het respect knopje naar 0 draaien.
Als ie dan inziet dat ie fout bezig is heb jij hem netjes duidelijk gemaakt dat ie ongelijk had (jij tevreden) en heeft hij weer wat geleerd (hij tevreden).

1 instance is wat groter, dat is op zich wel vaag.

Er zijn er toch 2 wat groter?

Btw, kan je niet zien of een deel van die 16MB shared is? In unices bijvoorbeeld gebeurt het regelmatig dat van de 16MB maar 6MB "non-shared" is...

Dat werd namelijk ook door een Microsoft-developer beweert, tijdens een presentatie van hun over WinXP en .NET, dat wat Gerco al ergens vertelde over codepages die niet dubbelgebruikt worden, zolang er niet naar geschreven is.

[Verwijderd]

Waarom? Nou omdat als iemand loopt te zeiken dat Linux sux maar geen goede argumenten geeft jij daar dan ook serieus op ingaat? Ik denk het niet. Dit forum is IMHO niet gediend bij trolls, wel bij serieuze discussies. Wil je zeuren over een platform? Prima, kom maar met argumenten. En over .NET zijn genoeg zeikpunten te verzinnen, maar memusage is er niet een.

[rant target=".NET"]
(1 waar ik me bv aan erger is de CLSCompliance attribute, die de compiler in een mode zet die alle code checkt aan de hand van CLS compliance rules (die ook door FxCop worden gebruikt bv, een soort lint voor .NET) en dus errors genereert wanneer iets niet volgens de regels is. Als je in een abstract base class een protected member hebt met een '_' prefix, dan compileert dat dus niet, maar een private member met een '_' prefix weer wel. Nu is een protected member altijd private in een inherited class en een abstract base class moet altijd geinherit worden, maar Microsoft wil dit niet veranderen zeiden ze tegen me, en blijven protected members in abstract base classes als public zien. Ik moet dus nu code gaan zitten wijzigen, wat interfaces gaat breken. En dat sux ass. ).

Een ander is bv de zeer crappy implementatie van SqlParameter class. De precision parameter in de constructor wordt intern in de property set_Precision gezet, en daar checkt ie of de value niet groter is dan 38 (?). Dit is ongeacht het type van de SqlParameter. Dit sux ass, want een SQLServer float heeft precision 53 en genereert dus altijd een error, je moet dus zelf je precision limiteren op 38, die overigens hardcoded er in zit.

Ja .net is leuk, maar sommige dingen sucken zwaar. Maar ach, daar komen we ook wel weer overheen

[/rant]

[Verwijderd]

Shared mem: dat is onder windows niet gebruikelijk. Maar ik ga ff checken.

[edit]
Het is wel vaag, elke nieuwe instance vreet 3 a 4 MB van de available mem af, en de thread start addresses van de processes zijn allemaal hetzelfde, althans volgens pview.exe. Blijft vaag, ik kan met de tools die ik hier heb, niet 1 2 3 ontdekken dat er gesharede mempages in gebruik zijn (geloof ik ook niet, ivm de appdomains) alle handles zijn volgens spy++ wel verschillend, wat er op duidt dat er geen gesharede resources in gebruik zijn.

[ACM]

[nohtml]

Verwijderd schreef op 18 augustus 2002 @ 17:55:
Nou omdat als iemand loopt te zeiken dat Linux sux maar geen goede argumenten geeft jij daar dan ook serieus op ingaat? Ik denk het niet.

Dat hangt er helemaal vanaf
Als ik in een bui ben dat ik wel es wil weten waarom het suckt dan zal ik er vrij serieus op in gaan.
Andere situaties zal ik het negeren of af doen met een opmerking ala "dat is onzin" of "dan heb je er nog nooit serieus mee gewerkt" oid.

Dit forum is IMHO niet gediend bij trolls, wel bij serieuze discussies.

100% mee eens. Niet bij trolls, niet bij flames, niet bij flame-uitlokkend-gedrag, niet bij kleinerend gedoe, oftewel: gewoon standaard discussie regels. Die zal iedereen wel eens "schenden", maar zo veel mogelijk er aan houden houdt het allemaal wel gezelliger.

Wil je zeuren over een platform? Prima, kom maar met argumenten. En over .NET zijn genoeg zeikpunten te verzinnen, maar memusage is er niet een.

Alle non-argumenten veeg je toch zo van tafel met een tegenvoorbeeld oid? (wat je dus nu al gedaan hebt).

ik moet dus nu code gaan zitten wijzigen, wat interfaces gaat breken. En dat sux ass. ).

Autch

Dit sux ass, want een SQLServer float heeft precision 53 en genereert dus altijd een error, je moet dus zelf je precision limiteren op 38, die overigens hardcoded er in zit.

Ook een leuke idd

Ja .net is leuk, maar sommige dingen sucken zwaar. Maar ach, daar komen we ook wel weer overheen

Elk platform zitten wel fouten in, ongeacht hoe je het woord platform definieert

[ACM]

Verwijderd schreef op 18 augustus 2002 @ 17:56:
Shared mem: dat is onder windows niet gebruikelijk. Maar ik ga ff checken.

[edit]
Het is wel vaag, elke nieuwe instance vreet 3 a 4 MB van de available mem af, en de thread start addresses van de processes zijn allemaal hetzelfde, althans volgens pview.exe. Blijft vaag, ik kan met de tools die ik hier heb, niet 1 2 3 ontdekken dat er gesharede mempages in gebruik zijn (geloof ik ook niet, ivm de appdomains) alle handles zijn volgens spy++ wel verschillend, wat er op duidt dat er geen gesharede resources in gebruik zijn.

Sja, ik weet ook niet meer of het nu van .NET of XP was.
Die developer was zelf van XP geloof ik, dus zal dan wel in XP gezeten hebben.

Het kwam er op neer dat als er bijv bij een fork (iig, weet dus ook niet in hoeverre dat geldt voor dubbel gestartte apps) oa het geheugen niet direct gekopieerd werd, maar in eerste instantie er gewoon naar verwezen werd. Totdat een van de pages gewijzigd werd, dan werd het pas gekopieerd naar een ander deel van het systeem geheugen.

Het zou opzich ook best aardig wat geheugen besparen als het ook voor meervoudig gestartte apps geldt, maar dat zou wel betekenen dat ze een enorm complex geheugen management afdwingen.

Anyway, die presentatie was voornamelijk een reclame praatje over XP en .NET en ook alweer een behoorlijke tijd geleden (windows XP was nog niet/net uit).

[LordLarry]

Verwijderd schreef op 18 augustus 2002 @ 17:42:
Je weet niet wat een application domain is? Wellicht wordt het dan tijd eens in .NET te duiken.

Dat blijkt maar weer

Over tegelijk opstarten:
hier een aantal versies opgestart, allemaal open, dus niet geminimized. (Ik heb even geknipt horizontaal ivm de grootte van het plaatje)

Inderdaad, je hebt gelijk. Het is tot .Net kwam iig geen standaard Windows geheugen management

1 instance is wat groter, dat is op zich wel vaag. Wat ook vaag was, is dat wanneer je ze collectief minimized (dus met die button op de quicklaunch bar) ze 16MB aan memory blijven houden, maar wanneer je dedicated op de minimize button klikt ze wel alle gui mem vrijgeven (ik heb dat niet ingebakken, dus dat is framework crap).

Anyway: memusage bij meerdere keren opstarten is per instance dus gewoon oplopend, en bij minimized guis dus marginaal per instance. taskbar programma's hebben geen guis dus ik betwijfel of dit op den duur veel ellende oplevert. Want als je 20 applicaties OPEN hebt, dus non minimized, ben je aardig druk bezig en heb je ook nu al veel mem nodig.

Het verschil tussen minimize en maximize is niet de GUI zozeer, maar gewoon het feit dat windows aanneemt dat als jij je programma minimized dat je er waarschijnlijk voorlopig niet veel mee wil doen. Das een perfecte candidaat om het geheugen van weg te swappen. Als je weer maximized swapped ie weer een deel wat dan direct gebruikt wordt terug.

Maar zoals eerder bewezen: dit geldt voor standaard windows gehuegen managemten, voor .net sta ik niet in

[Verwijderd]

LordLarry: Swappen van mem is nog wel degelijk in-use. Hier zie je dat bij minimizen alle GDI+ memory wordt gefreed en kennelijk ook alle resources die aan de CLR hangen. Overigens is dat bij IE bv ook zo (van 20MB naar 1MB).

ACM: Bij een fork praat je over 1 appdomain en meerdere processes / threads binnen dat domain. (in een .NET process that is ) Dus dan zou je 1 instance houden van de CLR en dus die initiele bak mem die je kwijt bent. Ik heb hier zo geen voorbeeld van een proces dat meerdere appdomains creeert om dit te testen.

In XP's kernel zitten idd een paar zeer vernuftige zaken, maar vziw zit de CLR daarbovenop en niet ertussen, dus een CLR process dat forkt, forkt binnen een membase, en is afhankelijk van de CLR omtrent mem management. (Dit om het 'managed' te houden). Wat ik gelezen heb is dat pas in Longhorn dit allemaal platgeslagen wordt. Dat duurt dus nog een erm... tijdje

[Gerco]

ACM schreef op 18 augustus 2002 @ 18:03:
[nohtml]
Alle non-argumenten veeg je toch zo van tafel met een tegenvoorbeeld oid? (wat je dus nu al gedaan hebt).

Ik heb het probleem van het geheugengebruik nog niet van tafel geveegd zien worden. Otis bevestigd juist dat het een berg geheugen gebruikt. Alleen heeft hij de claims van de topicstarter wat afgezwakt.

Mijn "berekening" was gebaseerd op de informatie van de topicstarter, maar als ik ze baseer op Otis zn cijfers scheelt het niet heel veel. Wel als je het over users en ASP pages hebt, maar daar heb ik het nooit over gehad.

En ik kan me inderdaad herinneren dat die marketer (die zich geen marketer wilde laten noemen op die lezing) zoiets zei over shared codepages, maar wat het precies was weet ik niet meer. Een codepage kun je toch per definitie niet naar schrijven?

[TheOneLLama]

LordLarry schreef op 18 augustus 2002 @ 18:25:
[...]


Het verschil tussen minimize en maximize is niet de GUI zozeer, maar gewoon het feit dat windows aanneemt dat als jij je programma minimized dat je er waarschijnlijk voorlopig niet veel mee wil doen. Das een perfecte candidaat om het geheugen van weg te swappen. Als je weer maximized swapped ie weer een deel wat dan direct gebruikt wordt terug.

Maar zoals eerder bewezen: dit geldt voor standaard windows gehuegen managemten, voor .net sta ik niet in

Als je naar de VM usage kijkt zie je dus dat er niets naar de swap verdijnt. Het is dus allemaal alloceren en dealloceren van GUI resources.
Is het veilig om na het vluchtig lezen van deze thread te concluderen dat vooral GUI's (winforms) veel geheugen kost in .NET? Hebben ze vast van Java gejat

[LordLarry]

TheOneLLama schreef op 18 augustus 2002 @ 22:39:
[...]


Als je naar de VM usage kijkt zie je dus dat er niets naar de swap verdijnt. Het is dus allemaal alloceren en dealloceren van GUI resources.
Is het veilig om na het vluchtig lezen van deze thread te concluderen dat vooral GUI's (winforms) veel geheugen kost in .NET? Hebben ze vast van Java gejat

Nee, VM Size is het aantal virtuele geheugen dat een applicatie gebruikt. Dat veranderd niet zo snel in de loop van een programma. GUI resources vallen daar niet onder. Ook niet onder Mem Usage trouwens. Het verschil wat je ziet bij de Mem Usage is o.a. een soort cache werking en de gesharde stukken geheugen zoals DLLs en code worden er wel bijgeteld. Er kunnen van de Mem Usage geen enkele conclusies worden getrokken. Hieronder wat webpages daarover.

http://alkaline.vestris.c...-faq/af-tech-memtask.html

Any operating system has a fixed amount of physical memory available. Usually, application need more than the physical memory installed on your system, for that purpose the operating system uses a swap mechanism: instead of storing data in physical memory, it uses a disk file.
On operating systems, such as Windows NT, Windows 2000 or UNIX, the memory is logically divided in pages. When the system needs a certain portion of memory which is currently in the swap (this is called a page fault) it will load all the corresponding pages into RAM. When a page is not accessed for a long time, it is saved back to disk and discarded.
If you look on the Windows NT Task Manager or the output from ps or top, Mem Usage is the working set size. It is the amount of physical memory which is directly (currently) allocated to the process. It can be accessed without causing a page fault. This includes pages shared with other processes. The Windows NT VM Size or the UNIX RSS value is the total private virtual memory allocated to the process.

http://miranda-icq.sourceforge.net/rich/

So if you really do want to measure memory use, what are the options? You could look at physical memory, but that will jump all over the place, and depend on what else is running and what it's doing, how much RAM you have, and is basically completely random. Another option is to measure the difference between total memory used when Miranda is running and when it's not. This is pretty reliable, but it's a pain and you still don't know what the cache is doing. Personally, I use the 'VM Size' column, because it's quick and provides fairly good consistency over multiple runs, but it has the problem that it doesn't indicate how much you're relying on the cache to do your work for you. The summary is basically, what are you trying to achieve?

PS: Again: Voor .Net sta ik niet in'