Zitat Zitat von RPG Hacker Beitrag anzeigen
Ich kann mir allerdings vorstellen, dass es spätestens bei 60 FPS trotzdem auffällt und die Anwendung verlangsamt oder Input-Lag erzeugt. Besonders, wenn man auch noch Physik-Berechnungen oder so drin hat.
Naja, wir leben ja nicht mehr in Zeiten, wo alles nur sequenziell abgearbeitet wird. Es laufen dort ja nebenbei Threads, die sich die Arbeit aufteilen. Ab C# 5.0 gibt es ja auch noch parallele Verarbeitungen. Dabei muss der Entwickler sich nicht mehr um jeden Thread selbst kümmern, sondern er regelt primär die Aufgabenverteilung. Die Erstellung der Threads geschieht dann zur Laufzeit automatisch. Hierbei wird dann auch automatisch entschieden, wie viele Threads gestartet werden sollen. Befindet sich ein Dualcore-CPU im Einsatz, werden zwei Threads gestartet. Bei einem Quadcore-CPU vier Threads, etc. Das kann erhebliche Vorteile bringen, aber auch Nachteile, wenn die ausführenden Aktionen nicht komplex genug sind und mehr Zeit beim Erstellen und Löschen der Threads verbraten wird.

GC.Collect() sollte man aber auch nur aufrufen, wenn man gute Gründe dafür hat. Es bringt nicht viel, ihn jedes Mal anzuschmeißen, da auch das wegschmeißen von Objekten nicht kostenlos ist, auch wenn viele das Gegenteil behaupten. Soll heißen: Der Prozessor braucht auch hier eine gewisse Rechenzeit. Wenn man den GC zu oft aufruft, kann es schon deutlich die Performance mindern. Es macht keinen Sinn, den GC anzuschmeißen, wenn nur eine Hand voll Objekte gelöscht werden sollen. Daher sollte man schon Performace-Tests durchführen, ob es wirklich was bringt.

In der Firma, wo ich arbeite, hantieren wir mit Millionen von Objekten rum (eine Software für Banken), und wir rufen lediglich nur ein einziges Mal den GC auf, wenn die Anwendung mit einer vorerst nicht wiederkehrenden Berechnung fertig ist. In diesem Zusammenhang empfehle ich mal eine Stack Overflow Foren-Diskussion: http://stackoverflow.com/questions/4...all-gc-collect