019
23.11.2006, 01:03 Uhr
ao
(Operator)
|
Zum Garbage Collector: Wenn er gut programmiert ist, arbeitet er nur dann, wenn das System Zeit übrig hat, vorausgesetzt, es ist immer so viel Speicher da, dass jede Anforderung direkt aus dem freien Heap bedient werden kann. Ob dann irgendeine Idle-Schleife läuft oder ob im Hintergrund der GC aufräumt, wen interessierts?
Und wenn der Speicher wirklich mal knapp wird, dann muss der GC eben einmal kurz anspringen und Platz schaffen, na und? In einem Programm ohne GC werden die Speicherblöcke dann freigegeben, wenn der Programmierer meint, sie nicht mehr zu brauchen. Ob das vom Performance-Profil her ein günstiger Zeitpunkt ist, oder ob es besser wäre, den Verwaltungskram auf gleich zu verschieben, weil ein anderer Thread gerade mit Vollgas rechnet oder zeichnet, darüber macht sich doch kaum einer Gedanken, oder? Und bei lose gekoppelten Nebenläufigkeiten ist es auch gar nicht vorherzusagen.
Damit will ich zeigen, dass ein Programm mit GC sogar die bessere Über-alles-Performance haben kann, weil der lästige Betriebskram dann erledigt wird, wenn ein bisschen Luft ist.
Davon abgesehen wird die Programmierung durch den GC erheblich einfacher und sicherer. Keine Speicherlecks mehr, und kein zerschossener Heap durch mehrfache Freigabe, ist doch toll. In C sind Speicherfehler die bei weitem schlimmste Klasse von Fehlern, was die Häufigkeit angeht und die Schwierigkeit, sie zu finden. In C++, mit Containern und Managed Pointern und so, gehts schon besser. Aber nach nem Dreivierteljahr als C#-Entwickler kann ich nur sagen: GarbageCollection ist einfach cool.
ao |
