LINQ Guidelines: Wann LINQ benutzen und wann foreach?

Hallo zusammen,

ich habe wahrscheinlich die letzten Tage mehr Google-Traffic verursacht als jeder andere 😄 Ich habe auch eine Menge gefunden und gelesen, bin aber bisher nicht auf einen grünen Zweig gekommen.

Ich habe kein Problem damit linq abfragen zu schreiben. Mein Problem ist viel mehr, dass ich die meisten Abfragen auch als foreach schreiben könnte.
Soweit ich das sehe, hat linq ein wenig Overhead und ist marginal langsamer als foreach aber besser zu lesen.

Habt ihr so etwas wie eine Richtlinie, an die ihr euch haltet bezüglich linq oder foreach?

Noch schlimmer ist es mit Parallel.ForEach und AsParallel --> ForAll.

Auch hier ist Parallel.ForEach marginal schneller als AsParallel (zumindest nach meinem Test, ich lasse mich gerne vom Gegenteil überzeugen) , aber für mich sieht linq strukturierter aus und ist meiner Meinung nach einfacher zu Erweitern.

Gibt es hier auch so etwas wie eine Richtlinie?

Es geht übrigens natürlich nur um Linq to Objects

Danke euch.

Hi...

ich versteh grad nicht worauf du hinaus möchtest.

Zeig mal Code-Schnippsel zur Verdeutlichung.

lg

Es geht eigentlich nicht um bestimmte Codeschnipsel. Sondern um die allgemeine Frage LINQ oder foreach. Ich könnte so gut wie alle Linq Abfragen auch mit einer foreach Schleife bewältigen, wann sollte ich also eins von beiden bevorzugen?

Linq ist ein wenig langsamer wegen dem Overhead, aber meiner Meinung nach besser zu lesen.
Gibt es hier andere Punkt nach denen ihr geht, oder gibt es absolute Ausschlusskriterien?

Mit der Parallel.ForEach und AsParallel ist es dasselbe Spiel.

irgendeineListe.AsParallel().Where(x => x % 2 == 0 && Math.Sqrt(x) > 945).ForAll(x => DoSomething(x));

Ich könnte das Beispiel auch genauso gut mit ForEach.Parallel umsetzen. Wo liegt der Vorteil von einem der beiden und in welchen Fällen sollte ich mich für eine der Möglichkeiten entscheiden?
Ich habe mehrere Performance-Vergleiche durchgeführt, aber daran konnte ich es nicht fest machen.

Hallo Rioma,

heute ist die Lesbarkeit des Codes fast immer wichtiger als das letzte Fitzelchen an Performance, siehe z.B. Mergesort langsamer als Bubblesort? [==> Nein, Messfehler / Aufwandsklasse vs. Mikrooptimierungen] (und auch Warum haben WinForms, DataGridView & LINQ eine gute Performance? [==> lineare Aufwandsklasse]).

Ich versuche es mal mit einem Vergleich: Man braucht nie Rekursion. Alles was man rekursiv lösen kann, kann man auch iterativ lösen, siehe z.B. Gibt es Rekursionen die sich nicht in eine Iteration umwandeln lassen? [iteratives Türme von Hanoi], aber es gibt einfach Probleme, bei denen sich Rekursion anbietet. Und wenn man so ein Problem hat, dann löst man es eben rekursiv, auch wenn man es iterativ machen könnte. Wenn du also ein Problem hast, bei dem du denkst, hey, das geht doch sehr einfach und übersichtlich per LINQ, dann nimm LINQ, auch wenn du es mit foreach machen könntest. Ich denke, da braucht man keine andere Guideline als die eigene Einschätzung bzw. Erfahrung.

herbivore

Hallo Rioma,

Parallel.ForEach und AsParallel

Grundsätzlich gilt hier auch die Aussage von herbivore, allerdings haben beide Varianten ein paar Besonderheiten auf die geachtet werden sollen. In When Should I Use Parallel.ForEach? When Should I Use PLINQ? ist das gut aufbereitet.

mfG Gü