Geschwindigkeitsbremsen und NACHTRÄGLICHE Optimierung



  • Was bremst mein Programm aus ? Ist die Frage die ich mir stelle,
    denn es ist sehr langsam.
    1. bremst es aus einenVektor immer neu mit push_back zu füllen und dann wieder zu leeren ?
    2. Sind Zufallsfunktionen wie std::random_shuffle(vector) geschwindigkeitsaufwändig ?
    3. braucht initialisierungen von Variablen viel Zeit ?
    4. Bremmst schreiben in eine Datei sehr ? (hab ich Vermutung, dass es so ist)
    5. Bremmst das Anzeigen in einem Element der Api (Winapi) ?
    6. Ständiges Aufrufen einer Funktion die ein Zeichen überprüft, 130 mal if ?
    7. bringt new und delete ein Speed und Performance +
    8. Wie sehr langsamen schleifen zum suchen nach einer Zahl in einem String mit 1-255 mit Leerzeilen ?

    Natürlich slowed alles ein wenig, logisch, aber was am meisten, grawirendsten und was gibt es für BÖSE sachen, die man vermeiden sollte ?

    ZU 6: map wär hier hilfreich gewesen, hab aber die einfach aus nem alten prog übernommen, ändern ?



  • 1. bremst es aus einenVektor immer neu mit push_back zu füllen und dann wieder zu leeren ?

    push_back bremst aus, wenn der reservierte Speicher überschritten wird. Speicher bleibt beim leeren reserviert. Wenn du abschätzen kannst wie groß der Vektor normalerweise wird, kannst du mit reserve den Speicher reservieren. Wenn nicht, wäre ein anderer Container vl eine bessere Wahl.

    4. Bremmst schreiben in eine Datei sehr ? (hab ich Vermutung, dass es so ist)

    ziemlich

    7. bringt new und delete ein Speed und Performance +

    Im Vergleich zu was? statisch allokierten Variablen? Nein, da ist new und delete ein ganzes Stück langsamer.



  • zu eins: nein. Einen vektor zu leeren verringert nicht den allokierten speicher. daher ist ein erneutes pushback sehr schnell. Zu beginn kannst du über .reserve die richtige Menge speicher reservieren.

    zu zwei: wenn für die objekte im vektor eine vernünftige swap funktion zur verfügung steht, sollte das kein problem sein

    zu drei: wenn du im konstruktor Sleep(10000) einbaust, dann ja.

    zu vier: Ja. Jede kommunikation zwischen RAM und "Benutzer" (egal ob schreiben auf Festplatte oder Konsole mit cout) ist immer langsamer

    zu fünf: Spezifizier mal

    zu sechs: Hä? if ist für integrierte Typen sehr schnell. Funktionsaufrufe kannst du mit inline vermeiden (ob das performance gibt, ist ne andere Frage)

    zu sieben: Zieh den stack vor.

    zu acht: versteh ich nicht

    zu zu sechs: map ist allgemein langsamer als vektor, weil der speicher nicht am stück im RAM liegt. Je nach Art der aufgabe kann eine map allerdings deutlich schneller sein.



  • zu fünf: als text in einer Text oder RichTextBox. und zwar jeder berechnete Buschtabe einzeln.
    zu acht: eine Schleife die von 1-255 in einer Datei liest
    while(std::getline(BLABLA))
    {
    str += BLA;
    }
    die liegt auch nochmal in ner schleife, FÜR JEDEN BUCHSTABEN.
    das selbe gilt für punkt vier.
    nur keine Datei sondern ein Vektor der größe 255

    btw: ein anderer Container ? Welcher denn für eine Sammlung von 255 ints ?
    EDIT: aso ja ok dann reserviere ich den, wird der autom. beim beenden wieder freigegeben ?



  • Du fragst die falschen Leute.
    Die richtige Ansprechsperson für diesen Fall ist dein Profiler.



  • Naja, das Kommunizieren mit einer EditBox ist das Selbe wie das Schreiben in eine Datei oder das Ausgeben über cout. Es ist (im Vergleich zu anderen Operationen) natürlich "sehr" zeitraubend. Reicht es nicht, das "Endergebnis" der Operation anzuzeigen?

    Eine schnellere Variante als vector gibt es nicht, wenn du mit POD's arbeitest, random access brauchst und keine Elemente am Anfang oder in der Mitte des vector löschen musst. Das Einzige, was schneller wäre, wären die normalen Arrays (auch wenn der Unterschied minimal und in deinem Fall wahrscheinlich nicht merkbar ist).

    Der Speicher von vector wird auch mit .reserve automatisch freigegeben, wenn der Destruktor vom vector aufgerufen wird.



  • Gilder schrieb:

    Naja, das Kommunizieren mit einer EditBox ist das Selbe wie das Schreiben in eine Datei oder das Ausgeben über cout. Es ist (im Vergleich zu anderen Operationen) natürlich "sehr" zeitraubend. Reicht es nicht, das "Endergebnis" der Operation anzuzeigen?

    Ja als alternative.
    2. Das Programm schläft nach einiger Zeit ein, wegen der brutalen Schleife, ist das mit dem Standart bewältigbar (komisches Wort, gibts das ?) ?
    oder mit Winapi, was MFC oder CLI da bietet gefällt mir nicht, warscheinlich dann auch mit SendMessage(hwnd,?) oder ?, kann man mir mal ein Beispiel geben ?
    es muss auch nur so alle Schleifendurchgang aktualisieren, mehr ist glaub ich eh nicht drin. Konsole braucht ja sowas nicht, deshalb nicht verschieben wenn hier keiner Antworten will, weils hier nicht hingehört.
    Dann antewortet eher wieder zu den Leistungsbremsen.



  • Shade Of Mine schrieb:

    Du fragst die falschen Leute.
    Die richtige Ansprechsperson für diesen Fall ist dein Profiler.

    👍
    Sehe ich auch so.

    Vor allem, da das alles recht Abhängig ist, wie oft und wie du gebraucht von den Sachen machst. Klar kann man sagen, welche Sprachfeatures teuer sind, aber wenn du konkret, wie du eine fertige Applikation hast, die optimiert werden soll, dann gehst du da am besten wirklich mit einem Profiler ran, weil du sonst an der falschen Stelle suchst.



  • Wenn du willst, daß dein Windows-Programm noch bedienbar ist, dann mußt du die zeitaufwendige Schleife in einen eigenen Thread packen. Und von diesem Thread aus, kannst du dann ab und zu die GUI aktualisieren lassen (welche verwendest du denn, MFC?).

    Bei deiner Beschreibung kommt es mir so vor, als ob du ersteinmal deinen generellen Algorithmus überarbeiten solltest (anstatt an einzelnen Schrauben zu drehen).



  • 1. Wenn es um Operationen an Containern/Arrays mit POD's geht, sollte eine Ausgabe bei JEDEM Schritt vermieden werden. Denn die Geschwindigkeit der Operationen aan POD's und der Ausgabe wo auch immer stehen in keinem Verhältnis. Vielleicht nur jeden xten Schleifendurchgang etwas ausgeben? (Modulo Operator)

    2. Natürlich kostet Ausgabe in EditBox Zeit. Allerdings glaube ich nicht, dass da die meiste Zeit bei drauf geht. Wenn du uns keinen Code zeigt, kann dir Niemand sagen, wo der Bottleneck deines Algorithmus stecken könnte.



  • ich wollte mich erst mal informieren, bevor ich dinge ändere.
    Mein Algorithmus kann nicht verbessert werden 🙂 Ne Spaß beiseite, der ist bis auf die Dateizugriffe eigentlich nicht veränderbar, bis auf ins kompliziertere.
    Man kann aber auch mehr oder weniger absichtlich eine langsamere Variante wählen



  • Aber 5 Zeichen pro Sekunde, das liegt glaube ich nicht am Algo selbst, also dem System. das kann ich mindestens um das zehnfache verbessern.
    MFC ja



  • 5 char's pro sekunde?
    Da ist ja ein Rechenschieber schneller 😃



  • da du uns keinen kontext gibst, d.h. wir nicht wissen was die "100%" sind, können wir auch nicht sagen, wie sehr (wieviel 😵 etwas bremst. also können wir bloss raten.

    > 1. bremst es aus einenVektor immer neu mit push_back zu füllen und dann wieder zu leeren ?
    vermutlich wenig

    > 2. Sind Zufallsfunktionen wie std::random_shuffle(vector) geschwindigkeitsaufwändig ?
    vermutlich wenig

    > 3. braucht initialisierungen von Variablen viel Zeit ?
    kommt auf den typ der variablen an, und mit was man sie initialisiert.
    vermutlich ganz ganz wenig

    > 4. Bremmst schreiben in eine Datei sehr ? (hab ich Vermutung, dass es so ist)
    vermutlich extrem

    > 5. Bremmst das Anzeigen in einem Element der Api (Winapi) ?
    vermutlich mittel

    > 6. Ständiges Aufrufen einer Funktion die ein Zeichen überprüft, 130 mal if ?
    vermutlich "mittel-wenig"

    > 7. bringt new und delete ein Speed und Performance +
    nein, new/delete KOSTET zeit
    grössenordnung "mittel-wenig"

    > 8. Wie sehr langsamen schleifen zum suchen nach einer Zahl in einem String mit 1-255 mit Leerzeilen ?
    vermutlich mittel

    > Natürlich slowed alles ein wenig, logisch, aber was am meisten, grawirendsten und was gibt es für BÖSE sachen, die man vermeiden sollte ?
    am meisten bremst, was am öftesten ausgefürht wird.
    wenn du 100.000 mal "wenig" bremst, ist das schlimmer, als wenn du 1x "extrem" bremst. nen?


Log in to reply