# GC Performance



## roflmao (24. Mrz 2012)

Hi,

warum ist ein GC oft schneller als manuelle Speicherverwaltung?


----------



## Final_Striker (24. Mrz 2012)

Ich würde nicht sagen das ein GC schneller wäre aber auf jedem Fall bequemer als eine manuelle Speicherverwaltung.


----------



## roflmao (24. Mrz 2012)

Final_Striker hat gesagt.:


> Ich würde nicht sagen das ein GC schneller wäre aber auf jedem Fall bequemer als eine manuelle Speicherverwaltung.


Na ja mit Destruktoren ist der Komfort Part halt völlig irrelevant, insofern geht es mir hier wirklich um Performance. Es gibt ja nicht wenige die sagen, dass der GC oft schneller ist. Und mich interessiert jetzt warum.


----------



## pro2 (24. Mrz 2012)

c++ - When can garbage collection be faster than manual memory management? - Stack Overflow


----------



## roflmao (24. Mrz 2012)

pro2 hat gesagt.:


> c++ - When can garbage collection be faster than manual memory management? - Stack Overflow


Der Thread wurde geschlossen weil er nicht ins Q/A Format passt, und keine der Antworten ist wirklich zufriedenstellend. Große Chunks kann ich auch mit manueller Speicherverwaltung bekommen.

Leere Destruktoren für die keine Markierungen für Exceptions mehr gesetzt werden müssen sind z.B. ein interessantes Argument, das ich mal gelesen habe; darüber würde ich gerne genaue Erklärungen und Benchmarks lesen.


----------



## maki (24. Mrz 2012)

Hi,


roflmao hat gesagt.:


> Na ja mit Destruktoren ist der Komfort Part halt völlig irrelevant, insofern geht es mir hier wirklich um Performance. Es gibt ja nicht wenige die sagen, dass der GC oft schneller ist. Und mich interessiert jetzt warum.


der "Komfort" keine Destruktoren schreiben zu müssen und sich fast keine Gedanken um die GC machen zu müssen und die daraus resultierende Tatsache dass man in Java Kompositionen auch als solche darstellen kann und nicht auf Aggregationen ausweichen zu müssen ist ein Vorteil was OOP betrifft.

Persönlich denke ich dass ein eventueller  Performancevorteil durch einen GC nur ein Nebeneffekt ist, nicht ein Hauptgrund für oder gegen einen GC.


----------



## roflmao (24. Mrz 2012)

maki hat gesagt.:


> Hi,
> der "Komfort" keine Destruktoren schreiben zu müssen


Muss man in C++ nie, siehe unique_ptr, shared_ptr und Container.



maki hat gesagt.:


> und sich fast keine Gedanken um die GC machen zu müssen


 Hä? Ja, das ist bei Destruktoren recht ähnlich.  (Und die können sogar Handels freigeben, Sockets schließen etc.)



maki hat gesagt.:


> und die daraus resultierende Tatsache dass man in Java Kompositionen auch als solche darstellen kann und nicht auf Aggregationen ausweichen zu müssen ist ein Vorteil was OOP betrifft.


 Dann zeig mal ein Beispiel, ich bin gespannt.



maki hat gesagt.:


> Persönlich denke ich dass ein eventueller  Performancevorteil durch einen GC nur ein Nebeneffekt ist, nicht ein Hauptgrund für oder gegen einen GC.


 Ne, der GC wäre eher ein notwendiges Übel, das man für Performance eingehen könnte, RAII ist da schon wesentlich komfortabler. (Aus oben genannten Gründen.)


----------



## roflmao (24. Mrz 2012)

roflmao hat gesagt.:


> Muss man in C++ nie, siehe unique_ptr, shared_ptr und Container.


Edit: Es sei denn natürlich, man möchte Dinge machen, die nicht direkt etwas mit Speicher zu tun haben. Dank der deterministischen Ausführung gibt es da ja noch ein paar Dinge.


----------

