Winform og Ramforbrug

Det lyder ikke voldsomt efter 2005 normer.

RAM er blevet billigere og applikationerne/frameworkene spiser bare MB RAM som
var det saltede peanuts.

Lad os tage et ikke Microsoft produkt: Borland JBuilder Enterprise Edition -
recommended RAM = 768 MB.

Det har ændret sig en del siden jeg havde havde Microsoft QuickC 1.0 på
en 360 KB floppy og mit C program på en anden 360 KB floppy ......

Hvis din klasse som jeg formoder stort set kun indeholder GUI kontroller
(altså ikke lige et integer array med en million elementer), så kan du ikke gøre
meget - det er Microsofts kode som bruger den RAM.

Vil programmet kræve mindre ram, hvis der ligger så lidt så muligt, funktionalitet i gui-klassen, modsat det er delt ud i mange klasser/dll'er? Jeg troede ikke det havde nogen betydning. Faktisk troede jeg, at det ville benytte mere ram, idet at man ofte vil oprette flere instanser af div. klasser, jo mere man det et program op i mindre dele...

Programmet kunne sagtens have været bedre struktureret...ingen tvivl om det...

Jeg har fået optimeret initilizeComponent metoder, eftersom jeg benytter localisering, fik fjernet ca. 6000 linier ved kun at localisere de nødvendige elementer, såsom : location, size, font og et par stykker til...

Mit gæt er at ændringer i din kode vil påvirke RAM forbruget meget lidt.

okey, hvorfor optager det mindre ram, at køre med mindre objekter, når der dermed ofte vil eksistere flere af dem...?

Forholder det sig sådan ?

ja gør det ikke...? Jeg tænker på, for at tilgå en klasse og dens metoder, kræves en instans jo...og jo mere opdelt man laver kode, jo større vil behov da være for at oprette flere nye instanser...? giver det ikke lidt mening...? :)

I C# kan man benytte ref foran en in-parameter, det har jeg faktisk aldrig rigtig benyttet mig af, bør man det...?

alle klasser i c# er referencetypes og det vil derfor altid blive overført som reference.

ref bruges kun til valuetypes, der normalt ellers ville få overførst deres værdi til metoden. ved at bruge ref.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csref/html/vclrfRef.asp

ang. mindre ram forbrug ved flere og mindre objecter kan det måske skyldes GC'en i .net. Det er rigtigt at du opretter en del flere instanser af dine klasser når du skal bruge funktionaliten, men hvis disse instanser kun findes i et lille scope bliver de jo nedlagt igen. Du vil derfor kun have instanser til klasse du rent faktisk har brug for, modsat en super-kæmpe-klasse som loader alt muligt du måske kun vil få brug en enkelt under hele programmets køretid.

øh

prøv lige og kør:

using System;

class MainClass
{
    private static void Test1(int i1)
    {
        i1 = 456;
    }
    private static void Test2(ref int i2)
    {
        i2 = 456;
    }
    private static void Test3(string s3)
    {
        s3 = "DEF";
    }
    private static void Test4(ref string s4)
    {
        s4 = "DEF";
    }
    public static void Main(string[] args)
    {
        int i1 = 123;
        Test1(i1);
        Console.WriteLine(i1);
        int i2 = 123;
        Test2(ref i2);
        Console.WriteLine(i2);
        string s3 = "ABC";
        Test3(s3);
        Console.WriteLine(s3);
        string s4 = "ABC";
        Test4(ref s4);
        Console.WriteLine(s4);
    }
}

arne_v>> hvad øh'er du over? det er jo netop den opførsel man måtte forvente ved ref-keywordet, og også det jeg, i hvert fald prøvede på, at forklare i mit indlæg.

jeg syntes at du påstod at ref kun var til value types ??

nu kan det jo diskuteres hvad en streng er... en immutable referencetype der opfører sig som en valuetype. er det ikke et spørgsmål om ord? det er rigtigt at rent teknisk er en string en referencetype, men i mit hoved kunne den lige så godt være en valuetype.

string er lidt speciel men det er det samme for mere normale class'es:

using System;
using System.Xml;

class MainClass
{
    private static void Test1(int i1)
    {
        i1 = 456;
    }
    private static void Test2(ref int i2)
    {
        i2 = 456;
    }
    private static void Test3(string s3)
    {
        s3 = "DEF";
    }
    private static void Test4(ref string s4)
    {
        s4 = "DEF";
    }
    private static void Test5(XmlDocument xd5)
    {
        XmlDocument xd5new = new XmlDocument();
        xd5new.LoadXml("<after/>");
        xd5 = xd5new;
    }
    private static void Test6(ref XmlDocument xd6)
    {
        XmlDocument xd6new = new XmlDocument();
        xd6new.LoadXml("<after/>");
        xd6 = xd6new;
    }
    public static void Main(string[] args)
    {
        int i1 = 123;
        Test1(i1);
        Console.WriteLine(i1);
        int i2 = 123;
        Test2(ref i2);
        Console.WriteLine(i2);
        string s3 = "ABC";
        Test3(s3);
        Console.WriteLine(s3);
        string s4 = "ABC";
        Test4(ref s4);
        Console.WriteLine(s4);
        XmlDocument xd5 = new XmlDocument();
        xd5.LoadXml("<before/>");
        Test5(xd5);
        Console.WriteLine(xd5.OuterXml);
        XmlDocument xd6 = new XmlDocument();
        xd6.LoadXml("<before/>");
        Test6(ref xd6);
        Console.WriteLine(xd6.OuterXml);
    }
}

okaaay... hm... det var ikke helt den opførsel jeg havde forventet, men man lærer noget nyt hver dag.

I Test5, der kan vi da godt blive enige om at der kommer en reference til xd5 med ind i metoden, eller ville man ikke kunne gøre det her:

        private static void Test5(XmlDocument xd5)
        {
            xd5.LoadXml("<after />");
        }

Men når det er en reference man har fået med, hvorfor kan man så ikke sætte den reference lig med en anden?

value type med ref:
  der sendes en kopi af værdien over
      man kan rette i kopien af værdien men ikke i originalen

value type med ref:
  der sendes en adresse på værdien over
      man kan rette i værdien som er originalen

reference type uden ref
  der sendes en kopi af adressen på objektet over
    man kan rette i objektets indhold fordi kopien peger på samme objekt som originalen
    men hvis man lader kopien pege på et nyt objekt så peger originalen stadig på det samme

reference type med ref
  der sendes en adresse på adressen på objektet over
    man kan rette i objektets indhold
    og man kan også sætte adressen til at pege på et andet objekt

pablopablo>

undskyld vi lige kører ud af en tangent

aha, cool... det med referencetypes, så fik jeg også det på plads... men hvorfor i alverden skriver de ikke det nogle steder. artiklerne omkring ref på msdn omhandler kun valuetypes.

hvis man søger på google efter ref keyword c# referencetypes får man6 hits, ref keyword c# valuetypes giver 1200 hits.

:)

det er nok mest relevant med value types

hvis man vil "ændre" en reference type så mener man nok i >90% af tilfældene at man vil
ændre objektets indhold og kun i <10% af tilfældene at man vil udskifte objektet
med et andet objekt

arne v >> det er helt ok ;) *jeg lyttede bare*

Lige for at jeg også får det helt på plads så...når man ikke bruger ref foran inparametre, så oprettes en kopi og originalen vil derfor ikke blive påvirker, modsat en ref...

ja

ok, men man bruger ikke ref. for at mindste ramforbruget vel...

Det jeg egentlig fisker efter er, om det generelt er ok at def. så små objekter som mulige, så det egentlig er lige meget hvor og hvor mange man opretter, de vil jo blive hapset af garbage Collectoren...eller er der et trick...?

nej

som jeg har forsøgt er forklare før så tror jeg at RAM forbruget af en win forms app
er primært bestemt af Microsoft og ikke af dig

jeg vil ikke mene at der er så lige meget... det hele handler om scopet af dine variabler. Hvis at de er oprettet som fields i din main-form, så vil garbage-collectoren aldrig få lov at nedlægge dem, da der bliver ved med at være reference til dem. Nu er det jo svært at komme med konrekte teknikaliteter når vi ikke kender din opbygning, men jeg mener at små objecter der hyppigt bliver oprettet og nedlagt igen vil fylde mindre i længden en store objecter der bliver ved med at blive hængende i programmet.

arne >> læg et svar...

ok