Klotzkopp

Das ist völliger Unsinn. Deine 15,36MB pro 1,28 Sekunden sind doch nichts weiter als auf andere Einheiten umgerechnete 100 MBit/s. So viele Daten sind wegen der großen Entfernung immer gerade unterwegs. Nirgendwo in der Aufgabe steht, dass nicht mehr auf einmal gesendet werden kann. Woher nimmst du das?

Zähl doch mal deine x, a und b nach. Du hast da mehrfach eins zuviel.

In den ersten 1,28 Sekunden wird gar nichts übertragen, denn so lange dauert es ja, bis das erste Bit überhaupt ankommt. Wie lange dauert es vom Senden des ersten bis zum Senden des letzten Bits? Wie lange dauert es vom Senden des letzten bis zum Empfangen des letzten Bits? Diese beiden Zeiten musst du einfach nur addieren.

Es sollte dir auffallen, dass hier nirgendwo die Dateigröße auftaucht. Heißt das, es dauert immer gleich lange, egal wie groß die Datei ist? Und das hast du wie ausgerechnet?

Das ist eine ganz normale Berechnung der Übertragungsgeschwindigkeit, mit der Ausnahme, dass du wegen der großen Entfernung zusätzlich Zeit für die reine Ausbreitung benötigst. Die Zeit, die das Licht für die Strecke braucht, musst du also immer mit berücksichtigen.

Die Syntax ist dieselbe, das Leerzeichen ist weder vor noch nach dem Stern notwendig. Whitespace (Leerzeichen, Tabs, Zeilenumbrüche) ist weitestgehend bedeutungslos. Ausnahmen sind Präprozessordirektiven, Literale, und wenn durch Weglassen von Whitespace andere Schlüsselwörter gebildet werden. Ob du also deine Zeile so schreibst char*Variable=NULL; oder so char * Variable = NULL ;[/code] ist egal, das Ergebnis bleibt dasselbe.

Dasselbe.

println kann genau 1 Ding ausgeben, nicht 5.

Das kann nicht sein. Escape-Sequenzen gibt es ausschließlich im Quellcode. Vermutlich benutzt du nur irgendwelche Funktionen, die eigentlich für nullterminierte Strings gedacht sind, wie strcpy.

Wenn du mit "Formatierungszeichen" die mit Backslash eingeleiteten Escape-Sequenzen meinst: Gar nicht. Diese Darstellung existiert nur in deinem Quellcode. Schon der Compiler wandelt das um, das hat mit printf nichts zu tun. Du wirst dir eine Funktion schreiben müssen, die die betroffenen Zeichen durch die jeweiligen Texte ersetzt. Weil strcpy abbricht, wenn es ein Nullbyte vorfindet, denn das ist die Endmarkierung für C-Strings.

Das ist ein Include-Guard. Er verhindert, dass dieselbe Headerdatei mehr als einmal in eine .cpp-Datei eingebunden wird. So etwas gehört in jede Headerdatei (wenn du es also aus einer Headerdatei entfernt hast, war das ein Fehler), allerdings muss das benutzte Präprozessorsymbol in jeder Datei anders sein.

Die Header binden sich nicht zufällig gegenseitig ein? Das funktioniert nicht.

An deinem Code liegt's nicht. Nein, sollte man nicht. Standards gibt es nicht ohne Grund. Schau dir die Lizenz deines Compilers an, da steht drin, worauf du dich verlassen kannst. Das kann man grob zu "gar nichts" zusammenfassen. Das Verhalten deines Programms kann sich beim nächsten Compiler-Update ändern. Wenn du deinen Code gezielt auf bestimmte Compilerfeatures hin ausrichtest, solltest du dir über die Folgen im Klaren sein. Vermutlich ist für jeden Fall außer 0xCCCCCCCCCCCCCCCC gar keine Schleife drin. Was du meiner Meinung nach falsch machst, ist dass du dich an einem völlig irrelevanten Problem festbeißt. Der Sinn deines Tuns wurde hier ja schon mehrfach infrage gestellt. Du testest hier an Optimierungsfeatures herum, deren Anwendbarkeit auf echte Programme ich für sehr begrenzt halte. Du hast also herausgefunden, dass unter gewissen Umständen sinnlose Schleifen nicht wegoptimiert werden. Was bringt dir diese Erkenntnis? Meiner Meinung nach gar nichts.

Es gibt kein Fehlverhalten. Allenfalls eine auffällige Besonderheit. Von einem Fehlverhalten darfst du sprechen, wenn das Endergebnis nicht stimmt. Es gibt kein "richtiges" Optimieren. Kein Standard garantiert dir überhaupt irgendeine Optimierung, geschweige denn, dass solche Abweichungen nicht auftreten. Ich würde sagen, der Compiler optimiert deine Schleife weg, außer für 0xCCCCCCCCCCCCCCCC. Hast du mal den generierten Assemblercode verglichen? Ich tippe auf ein Problem im Optimierer. Dein Problem besteht meiner Meinung nach aussschließlich darin, dass der Compiler für einen bestimmten Wert deine Schleife nicht wegoptimieren kann. Sobald dein Code wirklich etwas tut, löst sich das Problem von selbst.

Willst du wirklich einen Button betätigen (also eine Benutzeraktion simulieren), oder willst du vielleicht einfach nur, dass bei Enter dasselbe passiert, was beim Drücken des Buttons passiert? Falls letzteres zutrifft: Verlagere das, was in dem Button-Click-Event passiert, in eine eigene Methode, und ruf genau diese Methode bei Enter auf.

Vermutlich suchst du nach Simulo. Und bitte nicht irgendwelche uralten Threads ausgraben, wenn dein Problem nicht dasselbe oder zumindest sehr ähnlich ist.

Was heißt, du kannst nicht dahin scrollen? Beschreibe bitte genau das erwartete und das beobachtete Verhalten.

Es ist wohl tatsächlich so, dass Control.Dispose das Steuerelement aus der Controls-Collection seines Parent-Controls entfernt. Siehe dazu: How to: Add to or Remove from a Collection of Controls at Run Time -> Erst Remove, dann Dispose

Erzähl doch mal ein wenig mehr über dein Programm und was es tut. Die besten Möglichkeiten zur Performancesteigerung liegen oft im falsch gewählten Algorithmus, aber dazu schreibst du gar nichts. Wenn ein bestimmter Container in jeder Situation der schnellste wäre, bräuchte man die anderen nicht. Welcher Container der beste für dich ist, hängt davon ab, wie du ihn verwendest.

An dieser Stelle wären jetzt mehr Details toll gewesen. Mit "es gibt Probleme" kann man so gar nichts anfangen. Ein GUI mit 500 Buttons ist in meinen Augen unbedienbar. Tritt das Problem auch bei "normaler" Verwendung auf? Grob gesagt ist jeder Prozess auf 10.000 Fenster beschränkt. Wenn der GC in deinem Fall nicht dazu kommt, die alten abzuräumen, wird dein Prozess irgendwann keine neuen Fenster mehr erstellen können. Das dürfte der Grund für die Exception sein. Es kann sein, dass du das durch Erzwingen der Garbage Collection beheben kannst. Solange es nur dazu dient, in einem Testprogramm ein anderes Problem reproduzierbar zu machen, kann man das vertreten.

Ist dir das Generationenkonzept des GC bekannt? Jeder Aufruf von Collect bewirkt, dass nicht freigegebene Objekte in eine höhere Generation kommen. Ein Aufruf von Collect zum falschen Zeitpunkt kann sich nachteilig auf Performance und Speicherverbrauch auswirken. Außerdem pfuscht man damit im Selbst-Tuning des GC herum. Es gibt Fälle, in denen die Verwendung von GC.Collect angebracht ist. Aber keinesfalls sollte das eine allgemeine Empfehlung zum Lösen von Speicherproblemen sein. Ich schon. Nur wenn man genau weiß, wie der GC arbeitet, sollte man ihm ins Handwerk pfuschen.

Keine Ahnung, dafür hast du nicht genug Informationen geliefert. Es ist immer noch nicht klar, in welchem Kontext dein Code steht. Ich verstehe nur Bahnhof. Erklär mir bitte, wie ein einzelner Klick dazu führen kann, dass dieser Code 30 Mal ausgeführt wird. Was genau ist denn das eigentliche Problem, das dich dazu gebracht hat, diesen Testcode zu erstellen?

Bitte nicht versuchen, solche Probleme durch Rumfummeln am GC zu lösen. In den allerallermeisten Fällen sollte man von GC.Collect die Finger lassen. Ist da noch eine Schleife drumherum, oder warum löst ein einziger Klick aus, dass das 30 Mal ausgeführt wird?

Ich meinte, wie oft der ganze oben gezeigte Code ausgeführt wird. Dass du da 7 * 60 Buttons erstellst, sehe ich selbst. Aber wie oft passiert das? Ins Verhalten des GC solltest du nur dann eingreifen, wenn du ganz genau weißt, was du tust, und wenn du sicher bist, dass du das Problem nicht anders lösen kannst.

Vermutlich gehen Windows irgendwann die Fensterhandles aus. Wie oft wird dieser Code denn ausgeführt?