Anwendung ist sehr viel langsamer bei Fortschrittsanzeige

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

Es gibt 44 Antworten in diesem Thema. Der letzte Beitrag () ist von jvbsl.

    Humax schrieb:

    alle neuen
    Tools => Options => Projects and Solutions => VB Defaults
    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!

    So abschließend habe ich es jetzt so realisiert:
    • Wenn der Anwender auch Unterordner mit durchsuchen will, dann wird die Progressbar.maximum auf die die Anzahl der Unterordner im Startverzeichnis gesetzt und dann immer wenn einer dieser Ordner durchsucht ist die Progressbar.value um 1 erhöht.
    • Wenn keine Unterordner durchsucht werden sollen, dann wird ja nur das angegebene Verzeichnis durchsucht, also habe ich die Progressbar.maximum auf Anzahl Dateien in diesem Ordner gesetzt.
    In beiden fällen wird die Progressbar jetzt nicht mehr oft aktualisiert und das Programm läuft mit Fortschrittsanzeige Flüssig.

    Danke an alle für die Tippss

    Wie schon erwähnt, ich kenne mich noch nicht wirklich so gut aus, aber man lernt ja dazu.

    Option Strict ist jetzt on, also kein case "True" mehr .

    Und wegen dem Select case oder If then , ist doch egal was ich nehme oder macht das so einen großen Unterschied. Für mich sieht es zumindest in diesem Fall übersichtlicher aus.

    Select case ist nunmal für Mehrfachverzweigungen und if für Einfachverzweigungen.
    Natürlich kannst du auch mit dem Fahrrad auf die Autobahn, aber dafür wurde sie nicht gebaut.

    Und erklär mal, wie

    VB.NET-Quellcode

    1. Select Case CBx_VersteckteDateien.Checked
    2. Case true

    übersichtlicher als

    VB.NET-Quellcode

    1. If CBx_VersteckteDateien.Checked Then

    sein soll.

    ThuCommix schrieb:

    Switch (Select Case) vs If

    Während Switch 5 Ticks braucht, braucht If nur einen 1 Tick.


    Das wäre für mich eine akzeptable Begründung. Allerdings weiß ich ja nicht worauf sich dein / dieser Test bezieht.

    Ich habe jetzt mal schnell mit Timer.intervall 1 laufen gelassen und eine einfache Abfrage gemacht mit einer Schleife die jeweils 1 Million mal durchlaufen wird.
    Weiß ja nicht ob das damit gemeint war, aber das Ergebnis ist nahezu identisch.
    4 mal waren beide gleich schnell fertig.
    3 mal war If then Else schneller.
    3 mal war Select case schneller.

    Schwankungen von 33-36 Millisekunden.

    Quellcode

    1. ​Private Sub Button6_Click(sender As Object, e As EventArgs) Handles Button6.Click
    2. Dim Ergebnis As String = String.Empty
    3. Dim abc As Integer = 0
    4. zähler = 0
    5. Timer1.Start()
    6. For schleife As Integer = 1 To 1000000
    7. My.Application.DoEvents()
    8. If zähler = 0 Then
    9. abc = 0
    10. Else
    11. abc = 0
    12. End If
    13. Next
    15. Timer1.Stop()
    16. Ergebnis = "If then Else dauerte: " & zähler & " Millisekunden" & ControlChars.NewLine
    17. zähler = 0
    18. Timer1.Start()
    19. For schleife As Integer = 1 To 1000000
    20. My.Application.DoEvents()
    21. Select Case zähler
    22. Case 0
    23. abc = 0
    24. Case Else
    25. abc = 0
    26. End Select
    27. Next
    29. Timer1.Stop()
    30. Ergebnis += "Select Case dauerte: " & zähler & " Millisekunden" & ControlChars.NewLine
    31. MessageBox.Show(Ergebnis)
    32. End Sub

    Humax schrieb:

    Während Switch 5 Ticks braucht, braucht If nur einen 1 Tick.
    Das wäre für mich eine akzeptable Begründung.
    Wat?
    Also was Sch... - egaleres als 5 oder 1 Tick gibts doch nu wirklich nicht.

    Wie deine Tests gottlob ja auch bestätigen.
    Allerdings sind auch die Tests selbst vollkommen irrelevant, denn in Reihe geschaltet zu diesen 1 oder 5 Ticks sind wohl 5 Millionen Ticks, oder wieviel deine Dateisuche dauern mag.
    Also um die Performance zu verbessern wirst du mit if statt Select maximal (!!!) 0,00001% rausholen können - wie gesagt: Was sch..-egaleres muss erst noch erfunden werden.

    Micro-Optimiereung :thumbdown:

    Merke: Es hat überhaupt keinen Sinn, Performance-Verbesserungen anzubringen, an Punkten, die von sich aus bereits überdurchschnittlich schnell sind im Verhältnis zu den anderen in Reihe geschalteteten Performance-Konsumenten.
    Und das hat dir doch auch deine Problemlösung gezeigt: Performance kann man nur an den Punkten verbessern, die unverhältnismäßig langsam sind. Die anderen Punkte sind irrelevant.

    Kennst du eiglich das Ohmsche Gesetz - Reihenschaltung von Widerständen? Ich glaub, die dort getroffene mathematische Formulierung lässt sich direkt auch auf den Performance-Konsum von Code-Einheiten übertragen.

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Sage ja nur, dass es eine akzeptable Begründung ist, nicht dass es ausreicht um meinen Code zu ändern.

    Counterbug schrieb:

    Du arbeitest so halt mit den falschen Mitteln, ob du richtig programmieren willst oder nicht, liegt am Ende natürlich bei dir.


    Jetzt soweit zu gehen zu sagen ich arbeite mit falschen Mitteln!? Naja hört sich eher wie ne Grundsatzfrage an, so wie was war zu erst da, Henne oder Ei.
    Wie gesagt, ich lasse mich gerne eines besseren belehren. Performance ist ja in diesem Fall widerlegt. Übersicht ist in diesem Fall ziemlich gleich, aber ich bevorzuge select case. Wenn es sonst keinen "wirklichen" Grund gibt - lasse ich es so.

    nein, ich meine in beiden Selects.
    Aber da liegt noch viel mehr im Argen, etwa Application.DoEvents ist sehr fragwürdig, und die TryCatches ebenfalls.
    Statt DoEvents wendet man wohl Threading an, und die TryCatches sollten enger gefasst sein, also nicht allgemein den Selbstaufruf umfassen, sondern eng begrenzt um genau um die GetFiles/-Folder - Codezeile, wo die Exception erwartet werden muss. Und sie sollten nicht jede Exception catchen, sondern nur die erwartete.
    TryCatch ist ein heißes Eisen

    @EDR Mikrooptimierungen dürfen auch nur so genannt werden, wenn sich nichts aufsummiert, man kann sich wundern was ein einzelner Tick so manchmal bringen kann.
    Außerdem werde ich mir nicht nehmen lassen eine Mikrooptimierung zu verwenden, wenn diese den Code mind. genauso leserlich hält(ist hier der Fall) ich nicht mehr Zeit dafür Brauche(ist hier der Fall) und dabei sogar noch Zeit spare, möge diese auch minimal sein(ist hier der Fall).

    @TE dein Test ist ziemlich nichts sagend, da der Timer sowieso nur eine Genauigkeit von ~55ms hat. Für soetwas verwendet man eine Stopwatch.

    Allein bei einer Million durchläufe bekomme ich außerdem bereits einen Geschwindigkeitsvorschub zwischen 180% und 250% und das ist verdammt viel für solch ein paar Zeilen Code...(Vorallem wenn man bedenkt, dass der Compiler das ja theoretisch optimieren könnte - tut er aber wohl nicht).
    Außerdem war der Unterschied im Debugging immer über 200% nur im Release hatte ich das volle Spektrum von 180%-250%.
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---

Facebook
Telefonspende