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 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.

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 ?

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.

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.

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.

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

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.

> 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?