Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Such as?


Probably referring to reference counting, but that's not exactly a new idea. Still makes for a performance hit using reference counting all over the place.


I hope not! Reference counting is horrible in terms of CPU time!


Citation?


If using something like shared_ptr in C++0x, it does come with some drawbacks (due to not having a strict ownership) as mentioned by Bjarne Stroustrup[1]:

Please don't thoughtlessly replace pointers with shared_ptrs in an attempt to prevent memory leaks; shared_ptrs are not a panacea nor are they without costs:

-a circular linked structure of shared_ptrs will cause a memory leak (you'll need some logical complication to break the circle, e.g. using a weak_ptr)

-"shared ownership objects" tend to stay "live" for longer than scoped objects (thus causing higher average resource usage)

-shared pointers in a multi-threaded environment can be expensive (because of the need to avoid data races on the use count)

-a destructor for a shared object does not execute at a predictable time, and the algorithms/logic for the update of any shared object is easier to get wrong than for an object that's not shared

[1] http://www.stroustrup.com/C++11FAQ.html#std-shared_ptr



There is no a priori reason to think that it isn't horrible in terms of CPU time. Anything that has to do more work just to manage memory is going to consume cycles, and usually a lot of them. In simple utility programs it might not be observable but in larger applications with more objects, or on slower hardware (phones, for example) the cost is palpable.

> We find that an existing modern implementation of reference counting has an average 30% overhead compared to tracing, and that in combination, our optimizations are able to completely eliminate that overhead. This brings the performance of reference counting on par with that of a well tuned mark-sweep collector. [-3]

Even the best tuned mark and sweep GCs are a drag on performance.

> Reference counting is expensive - every time you manipulate pointers to an object you need to update and check the reference count. Pointer manipulation is frequent, so this slows your program and bloats the code size of compiled code. [-2]

> "Unfortunately, reference counting is expensive in both time and space". [-1]

Also, the slide entitled "Why reference counting is slow" in some recent lecture notes go into some detail. [0]

[-3] http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2...

[-2] http://ocaml.org/tutorials/garbage_collection.html

[-1] http://www.rtsj.org/RTJPP/errata.html

[0] http://cs.nyu.edu/courses/fall12/CSCI-GA.2110-001/lectures/G...


If you use naive reference counting, yes. But reasonably tuned implementations of deferred reference counting are competitive.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: