System.Threading.Tasks.Parallel.ForEach VorTeile / Nachteile

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 4 Antworten in diesem Thema. Der letzte Beitrag () ist von Rattenfänger.

    System.Threading.Tasks.Parallel.ForEach VorTeile / Nachteile

    Hallo Liebe Gemeinde,

    ich wollte mal fragen ob jemand diese VB Funktion kennt und auch damit gearbeitet hat?
    Wenn ja gibt es irgendwelche nachteile bei der Funktion, oder irgendwas auf das ich achten muss?

    VB.NET-Quellcode

    1. System.Threading.Tasks.Parallel.ForEach(FoundRow, po, Sub(SettingsRow)
    2. 'Mach irgendwas
    3. End sub)
    4. )


    Gruß

    Wenn Du weißt, was es macht (für jeden einzelnen Bestandteil von FoundRow die Sub hintendran durchführen), dann kannst Du Dir doch ausrechnen, wann es sinnvoll ist, diese einzusetzen. Ich hab sie bisher noch nie gebraucht, da ich bisher keine Massendatenverarbeitung verwendet habe, die eine Nebenläufigkeit braucht. Das System wird ein gutes Stück ausgelastet, wird aber meist schneller fertig sein, als wenn Du jede Row in FoundRow nacheinander abarbeitest. Probier's aus. Mach Zeittests. Dann wirst Du sehen, ob es einen Vorteil bringt. Klar, dass die Row-Änderungen sich nicht gegenseitig beeinflussen dürfen.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Klar das es nur zum lesen sinnvoll, sobald irgendwas geschrieben wird muss ein Synclock rein.
    Hmm, nutze es grad zum ersten mal und frage stelle mir grad die frage,ob ich es nicht in fast jede Schleife reinzimmere :D :D :D .

    Immerhin Zeit ist geld :-).

    @Rattenfänger Ich hab viel mit Parallel.For() gearbeitet.
    Sinnvoll ist es, wenn die Aufgaben disjunkt formuliert werden können, z.B. Filter-Operatoren in der Bildverarbeitung, Verarbeitung mehrerer Bilder gleichzeitig usw.
    Debuggen kann man das wegen der Threads schlecht, deswegen ist es sinnvoll, im DEBUG mit einem Compilerschalter mit dem "einfachen" For() zu arbeiten.
    Wen Du weißt, was das einfache For für ein Resultat bringt, kannst Du das Parallel.For()-Resultat dagegen testen.
    Wenn Du ein SyncLock benötigst, ist das suboptimal, weil Du Dich da selbst ausbremst.
    Z.B. bei der Verwendung von Random, das ist nicht Thread-sicher.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    @RodFromGermany Werde erst mal klein anfangen und nur werte parallel lesen, das hilft mir schnon mal viel.
    Dann Versuchen Rechenoperationen die in einer For schleife gemacht werden mit parallel.for zu optimieren.

    Danke für den Hinweis die werte nochmal zu vergleichen!!! Hätte ich sicher nicht von mir aus gemacht :thumbsup: :thumbsup: :thumbsup: .

Facebook
Telefonspende