Tjänar man något i prestande på att ha en metod som static om man har många objekt?

Absolut. Static (eller Shared i VB) innebär att koden i metoden finns kvar i minnet och behöver inte laddas upp i en ny minnesarea. Nytt minne behöver allokeras* när du skapar en ny instans av en klass och exekverar en metod i den klassen. Det är en stor prestandavinst att undvika det, eftersom det kostar mycket att allokera minne (programmet måste fråga operativet om lov, som kontrollerar om det är okej.. osv).


*) brasklapp för hur CLR internt hanterar dettta:
Eventuellt men sannolikt vid "många objekt" allokeras nytt minne.
Det kostar nog mindre än vad man inbillar sig men gratis är det knappast... :)

Det var lite det jag misstänkte. Brukar ni ha många av era metoder som static? Egentligen kan man väl ha alla som static och skicka variabler som argument istället för att komma åt dem direkt. Är det en bra ide? Känns som om man förlorar lite av oo-känslan då.

Hm... Nu får vi inte feltolka Olas inlägg...

Jag tror Ola tolkade dig som att du ville ersätta static-metoder med vanliga metoder sin inte alls har något i en klass att göra.

T.ex.
Att du skulle göra om Show-metoden i System.Windows.Forms.MessageBox till non-static. Det skulle vara dumt då det inte finns något i klassen som är bundet till metoden.

Det där med minnet är bara aktuellt i det ögonblock du skapar ett objekt, inte när du anropar det.

Ditt objekt skapas ju bara en gång sedan använder du ju samma objekt, men det sliter inte på minnet.

Dessutom tror jag nästan att det går snabbare att köra utan static eftersom att det då inte blir så mycket kopierande av saker fram och tillbaka

Men om mina objekt som jag skapar inte innehåller massa metoder (eftersom de är static) så blir de väl mindre? Borde det då inte gå snabbare?

Metoder ligger aldrig i ett objekt. Det som ligger i objektet är bara objektets data (och möjligen referenser till virtuella metoder, jag vet inte hur det är implementerat i .NET).

Det spelar ingen, eller fruktansvärt liten, roll för prestanda ifall en metod är statisk eller inte. Den enda möjliga skillnaden är att en statiskt metod inte behöver en referens till objektet.

Med nästan absolut säkerhet finns det andra saker i din kod som du kan vinna oerhört mycket mer prestanda på att effektivisera.

<b>Det var lite det jag misstänkte. Brukar ni ha många av era metoder som static? </b>

De som är av typen utility functions.
Se t.ex. på Microsoft.ApplicationBlocks.Data.SqlHelper.ExecuteDataReader()
Det gör STOR skillnad i en ASP.NET applikation att många sådana slags metoder finns i minnet hela tiden (så länge ASP.NET-appplikationen lever!) i stället för att du skall skapa nya objekt varenda gång en användare stormar in på servern. Dessutom kan man utnyttja cachade SqlParams som lever kvar i minnet. (3000 användare samtidigt på din sajt, som skapar 40 Nya SqlParameters vid varje Request, alternativt inte gör det, vad är bäst tror du?... :-)

<b>Egentligen kan man väl ha alla som static och skicka variabler som argument istället för att komma åt dem direkt. Är det en bra ide? Känns som om man förlorar lite av oo-känslan då.</b>

Nej, det tycker jag inte är en bra idé (eftersom du förlorar oo-tänket).
Där du behöver objekt som har tillstånd ska det vara vanliga metoder. När det är Utils är de static. Typ.

>Med nästan absolut säkerhet finns det andra saker i din kod som du kan vinna oerhört mycket mer prestanda på att effektivisera.

Håller helt med.

När man skriver kod skall man skriva så att den är enkel och överskådlig. Om resultatet inte blir tillräckligt snabbt får man försöka byta någon algoritm, ta bort någon onödig objektkopiering eller nåt.

Att en applikation skulle bli långsam beroende på static eller vilken datatyp man använder (integer/double/long) är inte troligt. Möjligtvis kan man titta på sånt inuti en liten loop som anropas många gånger.

Rasmus,

<b>Men om mina objekt som jag skapar inte innehåller massa metoder (eftersom de är static) så blir de väl mindre? Borde det då inte gå snabbare?</b>

Nej detta är inte sant. Om du har en klass som innehåller en metod och sen skapar du 500 objekt av denna klassen, så kommer bara metoden att finnas en gång i minnet. Samtliga av dina objekt kommer peka till metoden i minnet. Så att ersätta instansmetoder med statiskametoder för att spara minne är inte ett hållbart argument.

Ett klass och dess innehåll fyller ett väldigt viktig OOP koncept och det är <b>inkapsling</b>. Ett objekt känner till sin <b>state</b> (status) och kan agera olika utifrån den aktuella status som den har. En med hjälp en instansmetod kan du man sedan skicka med ytterligare information för att berätta för objektet hur den skall agera.

Om du har en metod som <b>inte</b> är beroende av state, så <b>kan</b> den vara en lämplig kandidat för att bli en statiskmetod, men det är inte garanterat att den bör bli det. Det beror på vad metoden skall göra och i vilka sammanhang den skall konsumeras. Om du har ett objekt med en metod som heter Display så skulle man kunna gör

MyClass c = new MyClass();
c.Display();

och

MyClass c = new MyClass();
MyClass.Display(c);

Oftast är det första faller man vill använda. Men som sagt det är en design sak, som man får sätta sig ner och planera. Verkligen tänka över hur objektet och dess metoder kommer att användas. En annan sak är att om du ersätter instansmetoder med statiskametoder kommer du troligen att få skicka in betydligt fler parametrar för att ersätta den interna state som inte längre finns - det innebär också att du kommer få hålla reda på den informationen någon annanstanns, vilket troligen kommer leda till betydlig otypligare och oläsligare kod.

Ett bekymmer med instansmetoder är om du har ett litet objekt, med ett fåtal metoder, där du konstant måste skapa nya objekt och sedan anropa metoden, för att sen göra dig av med objekten igen. Vad du riskerar att göra då är att tvinga fram en <b>Garbage Collection</b> mycket tidigare än du skulle behöva, vilket kan leda till stundtals försämrad prestanda.. Men som det sagts tidigare i tråden så innehåller troligen din applikation andra saker som är betydligt tyngre att genomföra.