C# icollection aantal object properties tellen

[siepeltjuh]

Hopelijk iemand die me kan helpen, want met Google en de search kom ik er niet uit.

Vanuit een tooltje dat ik geschreven heb voer ik een call uit naar Exchange Webservices en krijg dan een collection terug:

code:

ServiceResponseCollection<ServiceResponse> responseCollection;

Nu zou ik graag willen tellen hoevaak ServiceResponse uit de collection een bepaalde status heeft. Nu kan dat natuurlijk met een foreach, maar ik heb het idee dat dat netter/makkelijker kan. De ServiceResonseCollection heeft een GetEnumerator() methode, maar daar kom ik niet ver mee. Iemand die mij de juiste richting kan opsturen?

De code die denk ik dus sneller / in minder regels moet kunnen:

code:

ServiceResponseCollection<ServiceResponse> responseCollection;  
int Count = 0;
foreach(ServiceResponse response in responseCollection)
{
    if (response.Result == ServiceResult.Error)
    {
        Count++;
    }
}

[beany]

in de usings gedeelte: using System.Linq; (zo uit mijn hoofd)

code:

int aantal = responseCollection.Count(x => x.Result == ServiceResult.Error);

[ Voor 35% gewijzigd door beany op 13-02-2012 21:14 ]

[evolution536]

Het is de vraag wat nu belangrijker is, minder code, of een snellere werking / execution. Ik weet het niet zeker maar mij lijkt de loop een stuk sneller dan linq.

neemt niet weg dat het niet uit maakt als performance geen issue is.

[siepeltjuh]

Super.

Blijkbaar zit ik vandaag al wat te lang in de code. de count had ik wel gezien, maar niet de linq mogelijkheden daarvan. Met de oplossing inmiddels wat documentatie gelezen en hier kom ik een heel eind verder mee. Dank!.

Nu nog de afweging maken van compacte code vs. performance. Maar daar kom ik wel uit. top!

[pedorus]

evolution536 schreef op maandag 13 februari 2012 @ 21:50:
neemt niet weg dat het niet uit maakt als performance geen issue is.

Mwja, de performance van zo'n webservice weegt wat meer dan de kleine overhead die linq geeft denk ik zo

[alwinuzz]

Je code is toch prachtig zo met die Count( => ) !
LINQ is vaak veel leesbaarder en expressiever. Maak je over de performance maar niet druk, op in-memory collections zijn het gewoon method calls, lekker snel.

Je kan het altijd nog optimaliseren als je hebt gemeten dat de LINQ je bottleneck is.
Er was toch iets met premature optimization, en de bron van al het kwaad ofzo?

[sig69]

evolution536 schreef op maandag 13 februari 2012 @ 21:50:
Het is de vraag wat nu belangrijker is, minder code, of een snellere werking / execution. Ik weet het niet zeker maar mij lijkt de loop een stuk sneller dan linq.

Ik denk dat linq onderhouds precies hetzelfde doet

[Haan]

Van wat ik er van weet is de Linq implementatie goed uitgedacht. Bijvoorbeeld zal het aanroepen van Count() eerst kijken of de collectie een Count property heeft (bij een List bijvoorbeeld), en alleen echt gaan tellen als deze property ontbreekt. Hoewel er in dit geval natuurlijk sowieso geteld moet gaan worden

[ Voor 12% gewijzigd door Haan op 14-02-2012 11:53 ]

[beany]

evolution536 schreef op maandag 13 februari 2012 @ 21:50:
Het is de vraag wat nu belangrijker is, minder code, of een snellere werking / execution. Ik weet het niet zeker maar mij lijkt de loop een stuk sneller dan linq.

neemt niet weg dat het niet uit maakt als performance geen issue is.

Linq lijkt iets dat niet erg performance vriendelijk is. Zo 'voelt' het ook aan als je er meer aan het programmeren bent. Maar mijn ervaring is dat Microsoft goede optimalisaties toepast op Linq statements. En vooral bij wat complexere queries moet je er niet aan denken dat je die zelf moet uitprogrammeren met IF's en FOR's/FOREACH's

[YopY]

mbt performance moet je het ook iets breder zien: Door gebruik te maken van Linq, of eigenlijk (abstracter gezien) functioneel programmeren, geef je veel duidelijker aan het systeem door wat je wilt - in dit geval een count van het aantal errors in een collectie. In een ouderwetse for-loop geef je aan dat je een counter wilt, een item uit een lijst wilt halen, een andere counter conditioneel wilt ophogen, etc.

In de functionele stijl kan een compiler / VM het geheel veel beter optimaliseren, al naar gelang wat je precies wilt. Een voor de hand liggende optimalisatie op moderne systemen is bijvoorbeeld het opdelen van de collectie in stukken en de count laten uitvoeren in losse threads, hierbij het resultaat van elke thread ook weer bij elkaar optellen. Zelfde resultaat, maar omdat je veel minder aangeeft hoe hij het moet doen kan je computer het veel sneller doen door beter gebruik te maken van je systeem.

Op lijstjes van <100 entries zal het verschil er niet zijn, maar d'r zijn genoeg toepassingen waar je veel grotere lijsten hebt.

Heb zelf eens een kort testje gedaan in Scala. In Scala heb je gewone lijsten, maar hier kun je parallelle lijsten van maken waarop de functies multithreaded uitgevoerd worden. Een filter (alle cijfers deelbaar door 3 eruit halen) op een lijst van 200 miljard (oid) random cijfers duurde normaal 1500 ms, met CPU loads die regelmatig piekten tot 600%. Op een parallelle collection duurde het maar 30 ms, met CPU loads die onder de 100% bleven.

tl;dr: met Linq / functioneel programmeren geef je veel meer je intentie aan, bij traditionele for-loops geef je exacter aan hoe je wilt dat het systeem iets doet.

[sig69]

YopY schreef op donderdag 16 februari 2012 @ 10:26:
Heb zelf eens een kort testje gedaan in Scala. In Scala heb je gewone lijsten, maar hier kun je parallelle lijsten van maken waarop de functies multithreaded uitgevoerd worden.

Dat kan in C# uiteraard ook.

Een filter (alle cijfers deelbaar door 3 eruit halen) op een lijst van 200 miljard (oid) random cijfers duurde normaal 1500 ms, met CPU loads die regelmatig piekten tot 600%.

600%? Zo'n cpu wil ik ook!

Op een parallelle collection duurde het maar 30 ms, met CPU loads die onder de 100% bleven.

Geen idee hoeveel het in C# zou schelen, geen zin om te proberen...

...

[Matis]

sig69 schreef op donderdag 16 februari 2012 @ 10:35:
600%? Zo'n cpu wil ik ook!

Veel taskmanagers (waaronder die in Ubuntu) laat de percentages per core zien. 600% zou kunnen duiden dat hij 6 cores voor 100% belast. Dat is een veel beter beeld dan dat ie aangeeft hoeveel van de totale cores ie in gebruik heeft.

Als ik soms een proces heb dat 100% op een core gebruikt. Met een oct-core zou je dan maar 12,5% belasting zien, wat soms niet eens opvalt.