[C#/OO algemeen] Private static methods... Waarom?

[Dricus]

Als ik met behulp van de refactoring van MS Visual Studio 2005 (VS) een stuk code verhef tot method (met behulp van code selecteren, rechts-klik, 'Refactor', 'Extract Method...'), dan maakt VS daar in sommige gevallen een private static method van. Dit gebeurt als de geselecteerde code geen object state raadpleegt of wijzigt. Nu snap ik wel dat het in zulke gevallen mogelijk is om van zo'n stuk code een static method te maken. Wat ik me alleen afvraag is wat daar nu precies de voordelen van zijn. Ik heb er de MSDN library op nageslagen, maar MS geeft daarin geen antwoord op deze vraag.

Zelf kan ik op basis van mijn kennis in ieder geval twee mogelijke voordelen verzinnen. Wat ik me afvraag is of er nog meer zijn. Dit is mijn voorlopige lijst:
[list]• De this pointer wordt niet doorgegeven aan static methods, dit scheelt dus een beetje ruimte op de stack (en misschien ook een klein beetje performance?).

Dit voordeel zal in veel gevallen marginaal zijn denk ik.
• Zolang je de this pointer niet zelf handmatig gaat zitten doorgeven weet je zeker dat de betreffende method niet in staat is de state van je object aan te passen of te raadplegen.

Dit zou kunnen helpen in het zuiver houden van je code als het gaat om het verdelen van verantwoordelijkheden over methods. Private statics zijn dan je 'utility' methods. Door ze static te maken en te houden dwing je af dat ze dat ook blijven.

NB: Het gaat me vooral om de voordelen van het gebruik van private static methods. Het staat je natuurlijk vrij om de discussie enigszins te verbreden. Ik ben bijvoorbeeld ook wel benieuwd of er nog eventuele nadelen aan zitten.

Ik *denk* dat deze thread beter past in SEA dan in PRG. Bij voorbaat excuus aan de mods als dit een foute inschatting is .

[whoami]

Performance wise is een static method beter.

Als je Resharper hebt geinstalleerd, dan zal je merken dat Resharper ook steeds voorstelt om dergelijke methods static te maken.
Of, als je een code-analyse doet met FxCop, dan gaat FxCop ook meldingen gaan geven dat je method x beter static maakt, omdat deze toch geen state gebruikt.

CA1822:

Members that do not access instance data or call instance methods can be marked as static (Shared in Visual Basic). After you mark the methods as static, the compiler will emit non-virtual call sites to these members. Emitting non-virtual call sites will prevent a check at runtime for each call that ensures that the current object pointer is non-null. This can result in a measurable performance gain for performance-sensitive code. In some cases, the failure to access the current object instance represents a correctness issue.

[ Voor 45% gewijzigd door whoami op 16-09-2009 12:57 ]

[Danot]

De grootste reden voor mij om een method static te maken is puur de leesbaarheid. Zodat je bij het gebruik van de methode meteen ziet dat je niet met een instantie van de klasse bezig bent.
Dat je performancewise er ook iets mee opschiet is bij het ontwerp van je code niet van belang. Een method is nou eenmaal static(in ontwerp) of is het niet.

[Verwijderd]

private static methods gebruik ik meestal bij utilities (e.g. date/time conversie), meestal gebruik ik public static methods (ook al valt dit stiekem buiten je discussie ) alleen bij factory patterns of verkapt in een singleton. Dan is het eigenlijk geen method meer, maar een property (althans in C#).

[Dricus]

whoami schreef op woensdag 16 september 2009 @ 12:52:
CA1822:

Waar heb je dit precies vandaan?

[RobIII]

Dricus schreef op woensdag 16 september 2009 @ 20:34:
[...]

Waar heb je dit precies vandaan?

Rocket science en dan 2 seconden je grijze massa gebruiken.

[ Voor 16% gewijzigd door RobIII op 16-09-2009 21:12 ]

[Dricus]

offtopic:
Sorry RobIII, m'n grijze massa was niet meer zo scherp gisterenavond .

Danot schreef op woensdag 16 september 2009 @ 12:57:
De grootste reden voor mij om een method static te maken is puur de leesbaarheid. Zodat je bij het gebruik van de methode meteen ziet dat je niet met een instantie van de klasse bezig bent.

Dat gaat bij een private static niet altijd op:

C#:

class Foo
{
  private static void StaticBar() { ... }

  public void Bar()
  {
    ...

    // Niet leesbaarder dan als StaticBar niet static was geweest
    StaticBar();

    // Zo natuurlijk wel
    Foo.StaticBar();

    ...
  }
}

Het vereist nog steeds enige discipline om leesbare code te schrijven .

Dat je performancewise er ook iets mee opschiet is bij het ontwerp van je code niet van belang. Een method is nou eenmaal static(in ontwerp) of is het niet.

Een method is niet nou eenmaal static in je ontwerp (dat geef je zelf eigenlijk ook al aan). Dat is hij om 1 of meerdere redenen mag ik hopen. En een reden om die method static te maken zou zomaar eens performance kunnen zijn, zeker in applicaties waar dat van belang is. Of performance bij het ontwerp van je applicatie van belang is hangt af van het type applicatie dat je schrijft. Het is IMHO niet zo dat performance per definitie niet van belang is bij het ontwerp zoals je hier suggereert.

[Janoz]

Danot's opmerking gaat niet over hoe de aanroep eruit ziet, maar over wat de impact van de aanroep is. Bij een static (private) methode kun je er gegarandeerd vanuit gaan dat de aanroep geen enkele invloed heeft op de state van je object. Zeker in de huidige praktijk, waarbij concurrency steeds belangrijker wordt, is dat erg prettig gegeven om van uit te kunnen gaan.

Eigenlijk zou je dus andersom moeten werken. Een methode is static, tenzij hij wat met de state van het object doet.

[ Voor 13% gewijzigd door Janoz op 17-09-2009 11:52 ]

[ACM]

whoami schreef op woensdag 16 september 2009 @ 12:52:
Performance wise is een static method beter.

Grappig, vziw is een private static method in java juist langzamer dan een non-static... 't Is alleen verschrikkelijk lastig terug te vinden waar ik dat gelezen had. Toen ik het een tijdje geleden in het kritieke pad van een cpu-intensieve applicatie aanpaste was het in mijn test in ieder geval significant sneller om geen private static calls te gebruiken.
[edit]
En uiteraard zit er nu met een nieuwe jvm nauwelijks nog verschil in... geen idee hoe groot de verschillen toen waren (ik meen iets van 5%).

In C#/.net zal het allicht anders zijn, al is het alleen maar omdat java anders met heaps en stacks werkt.

Moraal hiervan is overigens niet zozeer dat je voor de een of de ander moet kiezen, maar dat je moet uitkijken met wat je wel/niet om performance redenen aanpast. In de meeste gevallen is de performance winst toch maar marginaal, dan kan je beter kijken wat het beste in je code past.

[ Voor 7% gewijzigd door ACM op 17-09-2009 15:29 ]

[.oisyn]

ACM schreef op donderdag 17 september 2009 @ 15:17:
[...]

Grappig, vziw is een private static method in java juist langzamer dan een non-static... 't Is alleen verschrikkelijk lastig terug te vinden waar ik dat gelezen had.

Dat lijkt me érg onwaarschijnlijk. Bij een instance method moet er namelijk opgezocht worden welke methode er daadwerkelijk aangeroepen wordt (meestal via de vtable van een object waar een functiepointer in staat -> dubbele indirectie + pipeline stall). Bij een static method kan er direct naar een vast adres worden gesprongen. En bovendien kan er dan veel beter geinlined worden.

Die pipeline stalls komen omdat de CPU niet van tevoren weet waar hij naartoe gaat springen (zie ook .oisyn in 'nieuws: AMD biedt eerste quadcore-cpu voor minder dan 100 dollar'). De enige manier om hier onderuit te komen is als de JITer snapt dat een method van class of object niet wordt / kan worden geoverride (waar het advies vandaan komt om methoden final te maken in sommige situaties)

In C#/.net zal het allicht anders zijn, al is het alleen maar omdat java anders met heaps en stacks werkt.

Hoe anders? Dat hij de heap op een andere manier compact kan ik nog begrijpen, maar waarom zou hij anders met stacks werken? Daarnaast heeft dit probleem niet heel veel met stacks en heaps te maken

Toen ik het een tijdje geleden in het kritieke pad van een cpu-intensieve applicatie aanpaste was het in mijn test in ieder geval significant sneller om geen private static calls te gebruiken.

Dan wil ik weleens weten wat dat dan voor testcase was...

[ Voor 19% gewijzigd door .oisyn op 17-09-2009 15:32 ]

[curry684]

.oisyn schreef op donderdag 17 september 2009 @ 15:27:
[...]

Dat lijkt me érg onwaarschijnlijk. Bij een instance method moet er namelijk opgezocht worden welke methode er daadwerkelijk aangeroepen wordt (meestal via de vtable van een object waar een functiepointer in staat -> dubbele indirectie + pipeline stall). Bij een static method kan er direct naar een vast adres worden gesprongen. En bovendien kan er dan veel beter geinlined worden.

Dank voor exact verwoorden wat in mij opborrelde bij het lezen van ACM's post

[ACM]

.oisyn schreef op donderdag 17 september 2009 @ 15:27:
Bij een instance method moet er namelijk opgezocht worden welke methode er daadwerkelijk aangeroepen wordt (meestal via de vtable van een object waar een functiepointer in staat -> dubbele indirectie + pipeline stall). Bij een static method kan er direct naar een vast adres worden gesprongen.

Het gaat hier specifiek over private methods die al-dan-niet static zijn he? Bovendien zal in mijn test-case in beide gevallen de methode volledig inline-baar zijn geweest.

De enige manier om hier onderuit te komen is als de JITer snapt dat een method van class of object niet wordt / kan worden geoverride (waar het advies vandaan komt om methoden final te maken in sommige situaties)

Juist, wat met private methods in principe standaard zo is

Dan wil ik weleens weten wat dat dan voor testcase was...

Ik zit al te kijken of ik het nog kan reproduceren... maar dat is nog niet zo makkelijk omdat ik na die test vast nog wel meer eraan heb verandert Nog afgezien van het feit dat een andere jvm het verschil weer compleet weggepoetst kan hebben.

[.oisyn]

Ah ja, idd, private non-static methods zijn in feite ook gewoon final

Hier iig een test met niet-private methods:

Java:

class Base
{
    static int s() { return 3; }
    int d() { return 3; }
}

class Derived1 extends Base
{
    int d() { return 4; }
}

class Derived2 extends Base
{
    int d() { return 5; }
}

class Test
{
    public static void main(String args[])
    {
        final int numObjects = 64;
        final int numIterations = 100000000;
        
        Base[] objects = new Base[numObjects];
        
        for (int i = 0; i < numObjects; i++)
        {
            switch((int)(Math.random() * 3))
            {
            case 0:
                objects[i] = new Base();
                break;
                
            case 1:
                objects[i] = new Derived1();
                break;
                
            case 2:
                objects[i] = new Derived2();
                break;
            }
        }
        
        long t;
        int v;
    
        // test with static
        t = -System.currentTimeMillis();
        v = 0;
        for (int i = 0; i < numIterations; i++)
            v += objects[i % numObjects].s();
        t += System.currentTimeMillis();
        System.out.println("static result: " + v);
        System.out.println("static time: " + t);

        // test with dynamic
        t = -System.currentTimeMillis();
        v = 0;
        for (int i = 0; i < numIterations; i++)
            v += objects[i % numObjects].d();
        t += System.currentTimeMillis();
        System.out.println("dynamic result: " + v);
        System.out.println("dynamic time: " + t);
    }
}

Resultaat:

static result: 300000000
static time: 187
dynamic result: 415625000
dynamic time: 1297

Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode)

't Mooie is trouwens wel dat MSVC++ die hele eerste loop wegcompileert en direct gewoon 300000000 uitschrijft

[.oisyn]

Als ik trouwens de d() final maak en 'm verwijder uit Derived1 en Derived2, dan kom ik hierop:

static result: 300000000
static time: 187
dynamic result: 300000000
dynamic time: 203

Dit verrast me toch wel enigszins (dat er nog best een verschil in zit bedoel ik dan)

[ Voor 19% gewijzigd door .oisyn op 17-09-2009 16:01 ]

[ACM]

Ik heb mijn test-case weer kunnen reconstrueren. Met een kale JVM-aanroep van mijn 64bits 1.6.0_15 krijg ik voor de dynamische variant 4,1 seconde gemiddeld en voor de statische variant 4,4.

Ik hoor graag of ik fouten heb gemaakt, maar het enige verschil tussen de beide varianten is het woordje static in een aantal private functie-definities.

[.oisyn]

Heb je ze wel meerdere keren uitgevoerd?
Bij mij zijn ze praktisch even snel. De dynamische variant gemiddeld iets van 0.005 seconde langzamer, dat is op een tijd van 4.4s verwaarloosbaar.

[ Voor 13% gewijzigd door .oisyn op 17-09-2009 16:54 ]

[ACM]

.oisyn schreef op donderdag 17 september 2009 @ 16:54:
Heb je ze wel meerdere keren uitgevoerd?
Bij mij zijn ze praktisch even snel. De dynamische variant gemiddeld iets van 0.005 seconde langzamer, dat is op een tijd van 4.4s verwaarloosbaar.

Dat was een gemiddelde van 8x op de windows command line uitvoeren, waarbij de beide tijden behoorlijk constant rond die gemiddeldes zaten. Als ik ze met -XX+UseCompressedOops uitvoer wordt het verschil op mijn Vista 64bit een stuk kleiner (nog maar net in het voordeel van de dynamische). Op mijn 32bits Linux is de statische variant wat sneller overigens.
Dus het is blijkbaar platform- en aanroepspecifiek of en wanneer de dynamische variant sneller is.

[Dricus]

Ik heb de test van .oisyn geport naar C# om eens te kijken hoe de verschillen in C# zijn:

C#:

class Base
{
    public static int s() { return 3; }
    public virtual int d() { return 6; }
}

class Derived1 : Base
{
    public override int d() { return 4; }
}

class Derived2 : Base
{
    public override int d() { return 5; }
}

class Program
{
    static void Main(string[] args)
    {
        int numObjects = 64;
        int numIterations = 100000000;
            
        Base[] objects = new Base[numObjects];
        
        Random r = new Random();
        for (int i = 0; i < numObjects; i++)
        {
            switch((int)(r.Next(0, 3)))
            {
            case 0:
                objects[i] = new Base();
                break;
               
            case 1:
                objects[i] = new Derived1();
                break;
                    
            case 2:
                objects[i] = new Derived2();
                break;
            }
        }
            
        long t;
        int v;
        
        // test with static
        t = -System.DateTime.Now.Ticks;
        v = 0;
        for (int i = 0; i < numIterations; i++)
            v += Base.s();
        t += System.DateTime.Now.Ticks;
        System.Console.WriteLine("static result: " + v);
        System.Console.WriteLine("static time: " + new TimeSpan(t).Milliseconds);

        // test with dynamic
        t = -System.DateTime.Now.Ticks;
        v = 0;
        for (int i = 0; i < numIterations; i++)
            v += objects[i % numObjects].d();
        t += System.DateTime.Now.Ticks;
        System.Console.WriteLine("dynamic result: " + v);
        System.Console.WriteLine("dynamic time: " + new TimeSpan(t).Milliseconds);
    }
}

Het resultaat is:

static result: 300000000
static time: 62
dynamic result: 503125000
dynamic time: 672

Flink verschil vind ik. Als ik hem meerdere keren draai, dan zit de dynamic time tussen de 350 en 750 ms.

Ook zonder inheritance is het verschil tussen static en non-static aanzienlijk trouwens. Onderstaande test geeft resultaten van een test waarin Base.d niet als virtual is gemarkeerd en waar alleen Base.d wordt aangeroepen.

C#:

class Base
{
    public static int s() { return 3; }
    public int d() { return 6; }
}

Resultaat:

static result: 300000000
static time: 78
dynamic result: 600000000
dynamic time: 234

Static is hier dus een factor 3 sneller dan dynamic. Reden genoeg om daar waar dat mogelijk is gebruik te maken van static methods.

[Janoz]

Efficientie is erg leuk, maar persoonlijk vind ik Danot's argument sterker. Het zorgt voor overzichtelijkere, en daardoor beter te onderhouden code. Dat het efficiënter werkt is een mooi meegenomen bonus.

Door enkel efficiente in de overweging mee te nemen ben ik bang dat er best veel mensen zullen gaan zijn die koste wat kost dingen static gaan lopen maken terwijl dat eigenlijk helemaal niet zou moeten. Het is heel gevoelig voor Cargo Cult Anti-pattern.

[Dricus]

Ik formuleerde het wat te kort door de bocht. Ik vind Danot's argument ook sterker.

Ik besef me nu trouwens dat het performance argument nog behoorlijk gerelativeerd kan worden (wat ik in de OP al een beetje deed trouwens): het gaat in deze testcase wel over 100 miljoen aanroepen van de functie, waarbij het verschil over het totaal genomen 600 ms is (in mijn geval). Daar zal ik in veruit de meeste gevallen niet wakker van liggen.

[Grijze Vos]

Je testcase is niet correct Dricus, bij je Base.s() call heb je de array lookup weggehaald.

[.oisyn]

Ik mag hopen dat de compiler die array lookup sowieso niet uitvoert bij een aanroep van een static methode .

Althans... Hoe zit dat trouwens met sideeffects? Ik bedoel, de lookup zou een exception kunnen gooien, waardoor program behaviour in dat geval dus afhangt van hoe erg de compiler optimized.

[Dricus]

@Grijze Vos:
De C# compiler staat het niet toe dat je een static method aanroept in de vorm reference.StaticMethod(), het moet altijd in de vorm ClassName.StaticMethod(), tenzij het een method van de 'aanroepende' class zelf is natuurlijk. Een effect (en misschien het doel wel) hiervan is dat je de fout sideEffects().StaticMethod() (waarbij sideEffects() dus niet wordt aangeroepen, zoals dat in C++ het geval is volgens MSDN) niet kunt maken.

Als die array lookup in Java wordt weggeoptimalseerd (wat hopelijk wel zo is), dan doet mijn testcase effectief dus hetzelfde als die van .oisyn.

[ Voor 13% gewijzigd door Dricus op 25-09-2009 10:56 ]

[.oisyn]

Dricus schreef op vrijdag 25 september 2009 @ 10:54:
Een effect (en misschien het doel wel) hiervan is dat je de fout sideEffects().StaticMethod() (waarbij sideEffects() dus niet wordt aangeroepen, zoals dat in C++ het geval is volgens MSDN) niet kunt maken.

Euhm, waar staat dat precies? Het lijkt me namelijk nogal onzin, en dat is ook zo volgens MSVC++

[Dricus]

Hmm, dat had ik hier gelezen (in de note), maar het is me niet helemaal duidelijk of dit over C++ in het algemeen of over de .NET extensions van C++ gaat.

Edit: En hier dezelfde note voor VS2008.

Edit2: Het lijkt in die 2 pagina's wel over C++ in het algemeen te gaan. Heb jij dit in MSVC++ getest .oisyn?

Edit3: Net zelf even getest in MSVC2008. SideEffects() wordt wel degelijk aangeroepen inderdaad. Gek dat er dan zoiets in de MSDN library staat...

[ Voor 47% gewijzigd door Dricus op 25-09-2009 11:31 ]

[.oisyn]

't Lijkt me een duidelijk geval van documentation error. De bijbel zegt ook (met toevalligerwijs een expliciet voorbeeld erbij):

9.2/2
A static member s of class X may be referred to using the qualified-id expression X::s; it is not necessary to use the class member access syntax (5.2.5) to refer to a static member. A static member may be referred to using the class member access syntax, in which case the object-expression is evaluated.

C++:

class process {
public:
    static void reschedule();
};
process& g();

void f()
{
    process::reschedule(); // OK: no object necessary
    g().reschedule(); //  g() is called
}

En de MS compiler is dus gewoon conform

.edit: ik heb maar een comment gepost en 'm geflagged als content bug

[ Voor 8% gewijzigd door .oisyn op 25-09-2009 13:20 ]