Szerintem itt másról beszélünk. A cikk sajnos nem mond nekem semmit, mert nem derül ki belőle, hogy mit is mértek pontosan.
A malloc() drága, ebben egyetértünk. De a GC ugyanúgy kell, hogy hívjon malloc()-ot.
A malloc() és a free() ugyanis mindig lassú. Viszont a smart pointernek semmi köze a malloc-hoz.
Teszem azt, hogy leírod, hogy shared_ptr a = new int(12); Két malloc() hívódik itt. Előszor is a new-en keresztül meghívott malloc()-kal te foglasz memóriát.
A shared_ptr tartalmaz egy másik malloc-ot is, és egy ref count incrementet. Ha copy cstrja hívódik, akkor nincs másik malloc, csak ref-count művelet. Destruktor hívásnál van egy free() a ref-count mellett, ha elfogytak a referenciák.
Namost, ha a shared_ptr helyesen van megírva, akkor a belső malloc() lefut kb 2000 cpu cycle alatt. Ugyanis shared_ptr által hívott malloc mérete fix, ezért remekül lehet poolozni, ami egy konstans idő alatt végrehajott allokáció. Ez a konstans időben végrehajtott allokáció egy mutex hívásból és egy stack/láncolt lista műveletből áll.
Abban az esetben lehet szar a shared_ptr, ha ugyanazt a shared_ptr-t érték szerint gyakran másolgatjuk, és mindezt tőbb thread között. És ezt nem egy, hanem millió kicsi objektummal csináljuk.
De még ekkor sem nagyon szar. Ha az atomic inc/dec drága az adott platformon, akkor persze baj van.
Nekem úgy tűnik, hogy keverd a szezont a fazonnal.
A naív, memória-poolok nélküli malloc()-ozást hívod shared_ptr-nek, és ezt hasonlítod a GC-hez.
Gondolom, hogy a GC implementációk erősen memoria pooloznak. De ezt te is megteheted, GC nélkül is.
A fair összehasonlítás nem shared_ptr + naív malloc vs GC, hanem a shared_ptr + fast malloc vs GC lenne.
Remélem érthető volt :)))