Lange for-schleife umgehen

  • VB.NET

Es gibt 6 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    Lange for-schleife umgehen

    Nach einigen Spielereien in VB um mir mal anzugucken, was wielange braucht usw, kam ich auf die Idee, einen ziemlich langen String zeichen für zeichen durchzugehen und die einzelnen Buchstaben einzeln in eine Variable zu schreiben. Allerdings sind For-Schleifen von 1 bis 439177 ziemlich unperformant wie man sich vorstellen kann, und daher suche ich nach einer Alternative. Es geht also weniger um mein Problem, als den Ausweich auf etwas schnelleres für größere For-Schleifen

    VB.NET-Quellcode

    1. For i = 1 To SourceString.Length
    2. Dim ActualLetter As String
    3. ActualLetter = Mid(SourceString, i, 1)
    4. 'ActualLetter = "a" Wenn ich das einfach a setze, dauerts genau gleich, also es liegt tatsächlich an for, statt der Funktion selbst
    5. Ausgabe &= ActualLetter
    6. BackgroundWorker1.ReportProgress(CInt(i / Length * 100)) 'Musste sichergehen das der Prozess weiterläuft weil der so lange dauert^^
    7. Next
    Der gesamte Code ist Unperfomant, nicht die For-Schleife.

    1. Mid() ist eine VB6 Funktion
    2. Strings mit & zu verknüpfen = Unperformant. Nutze den StringBuilder
    3. Ein String ist bereits ein Array vom Typ Char, heißt Mid() oder die .NET Methode Substring() kann man weglassen
    4. Wieso zerlegen und wieder zusammen setzten?
    Mid-> SourceString(i)
    Ist schonmal schneller...

    Statt Ausgabe &= -> StringBuilder

    ReportProgress nur aufrufen wenns nötig ist, also wenn wirklich eine etwas größere Veränderung da ist...

    Ansonsten wäre es nur noch schneller das Kopieren über Nativen Code direkt im Speicher zu machen, ansonsten nein...

    Ich poste es trotzdem mal durch die Ergänzung :P
    Und @Dodo: Nur zum testen der Geschwindigkeit...
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---
    Jup, ich wollte mal ausprobieren, ob es Unterschiede bringt in der Art "Wie" man etwas macht. Also ob es Unterschiede hat, welche Befehle man nutzt, auch wenn sie selben Nutzen haben und das Endergebnis dasselbe ist. Und so wie es aussieht ist es tatsächlich so. Also der StringBuilder macht seine Ausgabe ziemlich schnell erledigt und auch den Sourcestring mittels Index anzusprechen hat einiges gebracht. Von dem her hat sich das mal erledigt, thx ;D

    Mid() hatte mir mal meine Informatiklehrerin aus den VBA-Stunden eingetrichtert^^
    Das was langsam ist wird das String zusammensetzten sein, ich glaube Mike hatte da mal nen kleines Testprogramm geschrieben wo man sconh deutliche geschwindigkeits Unterschiede bei einem String mit 1000 Zeichen hat wenn man das &= oder einen StringBuilder nutzt.

    PS: Ja in der Schule wird kaum .NET beigebracht, weil das Lehrpersonal zu faul ist sich mit der aktuellen Materie auseinander zu setzten und lieber das weitergibt was sie vor 15 Jahren mal gelernt haben .. nämlich VB6.
    @BrowserKoopa:

    Sieht so aus, als wirst du bei deiner Lehrerin nichts lernen, außer, wie mans nicht macht. Also alles was sie von sich gibt, mit äußerster Vorsicht genießen, und selbst lernen, mit dem auf Buch Lesen empfohlenen. Beachte auch die Kritik anderer Bücher - es ist wirklich jede Menge Schrott unterwegs.

    Eins kannste jetzt gleich lernen:
    Die Frage nach Geschwindigkeit ist absolut total nachrangig.
    Wenn man ordentlich programmiert ist das Framework fast immer hinreichend schnell. Grade so Standards wie For - oder andere Schleifen - uninteressant - da ist nie OptimierungsPotential.

    Was absolut vorrangig ist: sauber geschriebener Code, insbesondere eine intelligente Aufteilung von Verantwortlichkeiten.
    Geschwindigkeits-Optimierungen kommen immer als allerletztes.
    Und wenn dann die Verantwortlichkeiten sinnvoll in Klassen strukturiert sind, dann geht man (ganz zuletzt!) hin in eine Klasse, und fummelt da am Algorithmus herum.
    ZB, wenn eine Liste durchsucht wird, kann man implementieren, sie sortiert zu halten, und dann mit Binär-Suche drauf losgehen - sowas steigert Performance.
    Und wenn der Code korrekt strukturiert und redundanzfrei ist, gibt es nur eine Stelle, wo diese Liste durchsucht wird. Wennde die nun auf Binärsuche umstellst haste gewonnen, aber fett.
    Du siehst: die Strukturierung ist nicht nur vorrangig vor Optimierung, sie ist Vorraussetzung dafür.

    Ah - was du noch lernen kannst:
    In .Net gibts für fast jede Standard-Anforderung auch eine Klasse, die diese Anforderung auf ausgezeichnete Weise umsetzt.
    Also fang jetzt nicht an, eine binäre Suche zu implementieren, sondern sieh dich im ObjectBrowser nach "BinarySearch" um.
    (Naja, eine selbstimplementierte BinärSuche ist vlt. eine Super - Übungsaufgabe)

    Aber trotzdem: Ganz wesentlich und spezifisch am Programmierstil in .Net ist, niemals draufloszuproggen, sondern immer erst Ausschau halten nach vorgefertigten Lösungen, die man nur einzubauen braucht. Wie gesagt: Die vorgefertigten Bauteile sind eigentlich immer von einer Qualität, die du mit selbst-programmieren einfach nicht erreichen kannst (Kunststück: im Framework sind tausende von MannJahren Arbeit investiert, ausgeführt durch SpitzeKlasse-Programmierer)

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