[c#] Methode aanroepen als argument

[Verwijderd]

Hallo, ik vroeg me laatst het volgende af:

als ik meerder keren een methode aanroep die iets returned, alleen maar omdat het minder regels code is. Scheelt dit dan veel performance, doordat de methode vaker wordt aangeroepen, of is de compiler slim genoeg?

code:

     ObjectOfClass x = new ObjectOfClass();
     ObjectOfClass2 y = ObjectOfClass2();
     for(loop)
     {
            y.Blaat(x.Lenght, x.GetList());
     }
  
     OF
  
     ObjectOfClass x = new ObjectOfClass();
     int l = x.Lenght;
     object o = x.GetList();
     ObjectOfClass2 y = ObjectOfClass2();
     for(loop)
     {
            y.Blaat(l,o);
     }

[RobIII]

In het eerste voorbeeld zal GetList telkens worden aangeroepen, uiteraard omdat deze elke keer andere waarden zou kunnen returnen. En het tweede voorbeeld wordt telkens met het eenmalig opgehaalde resultaat gewerkt.

[ Voor 23% gewijzigd door RobIII op 12-09-2007 22:48 ]

[Not Pingu]

De output van GetList() kan natuurlijk elke keer anders zijn (vanuit het oogpunt van de compiler dan) dus valt er weinig te optimaliseren. Methode 2 is natuurlijk een stuk sneller.

Zat die for loop er nou niet in, dan is de methods rechtstreeks uitlezen in de functie call wel ietsje sneller.

[farlane]

Ligt er maar helemaal aan hoe GetList() eruit ziet

[prototype]

Je zou dit niet moeten bekijken van een optimalisatie standpunt, want ik kan met bijna zekerheid zeggen dat hier niet je performance bottleneck zal liggen (de lijst zal zelf ongetwijfeld een property hebben die bijhoudt hoeveel elementen er in de lijst zitten, e.g. via een integer, en niet elke keer de list traversen om erachter te komen hoeveel elementen erin zitten. Qua complexiteit is het dus verwaarloosbaar. En als getList doet wat ik denk dat het doet, i.e. het returnen van een referentie naar een lijst, dan is ook dat vrij verwaarloosbaar.). Voor de rest is het al gezegd door RobIII, maar daar zou ik nog wel de aanvulling op willen maken dat je heel goed rekening moet houden met het feit dat je bij methode 1 actueel vraagt naar de lengte van de lijst (?). De reden waarom ik dit zeg is omdat het vaak zo is dat de lengte van de lijst een bepalende factor is in de guard van een lus, en bij lussen is het dan vaak ook van belang dat ze eindig zijn (en dat je dit ook kan bewijzen). Door operaties op lijsten zou je dit eventueel in het geding kunnen brengen doordat je de betreffende lijst heletijd in lengte doet varieren, maar wel zodanig dat deze nog voldoet aan de guard. Dit kan zowel binnen de loop alswel concurrent plaatsvinden (in het laatste geval kan je eventueel een concurrentmodificationexception dan krijgen, weet niet precies hoe BCL dit doet). Het gevolg is dat je dan een oneindige lus kan krijgen.

[ Voor 15% gewijzigd door prototype op 13-09-2007 01:54 ]