4 ms·

In C world yes, in C++ world no, because of weak_ptr.

asdfasgasdgasdg 6y ago
Weak_ptr in C++ only applies to shared_ptr, which is not used for most C++ pointers. Because of the atomic ops done on each copy, in performance sensitive contexts people aren't going to be using it.
- codr7 6y ago
  Been there, done that. I was writing an interpreter using shared ptrs all over the place. Performance was fine until I linked pthreads, at which point it took a nosedive forcing me to refactor the entire project. No one really tells you this. People will say don't use shared ptrs because they're slow, which is far from the whole truth. They're pretty darn fast as long as you don't enable threading.
  - asdfasgasdgasdg 6y ago
    I would go a step farther and say that uncontended shared_ptrs are typically fine. The problem comes in when you have shared_ptrs that are frequently copied in more than one thread. That requires synchronizing the shared state across cores, sometimes across NUMA nodes. That's slow. The same thing goes for mutexes. Modern, uncontended mutexes are very fast. But they can start sucking resources when you're locking them from multiple threads at the same time.
  - benibela 6y ago
    >I was writing an interpreter using shared ptrs all over the place. I am doing that :/ In Object Pascal it is the standard memory management way. All strings and arrays are reference counted, and so I use it for all my own data structures as well I have not even added threading and I doubt I will, but the reference counting is already the slowest part Not sure what the alternative is
    - asdfasgasdgasdg 6y ago
      You can avoid reference counting overhead by using handles as described in this article. Each object in a slab would have just one reference, and you handles would be indexes into an array of them. Now, after you do that you will be on be hook for making sure you don't accidentally deallocate any of the objects that is currently in use. And it's not guaranteed to be faster. But it is one way to get around this issue.
      - benibela 6y ago
        I do not understand how this would help It would still need reference counting on the handles to know when the handle is not used anymore and the element in the array can be reused Without reusing handles it would surely run out of memory. Unless a full GC is used
  - vvanders 6y ago
    Shared pointers also defer ownership decisions and lead to memory leaks via cycles which is its own very special level of hell.

Weak_ptr in C++ only applies to shared_ptr, which is not used for most C++ pointers. Because of the atomic ops done on each copy, in performance sensitive contexts people aren't going to be using it.

codr7 6y ago
Been there, done that. I was writing an interpreter using shared ptrs all over the place. Performance was fine until I linked pthreads, at which point it took a nosedive forcing me to refactor the entire project. No one really tells you this. People will say don't use shared ptrs because they're slow, which is far from the whole truth. They're pretty darn fast as long as you don't enable threading.
- asdfasgasdgasdg 6y ago
  I would go a step farther and say that uncontended shared_ptrs are typically fine. The problem comes in when you have shared_ptrs that are frequently copied in more than one thread. That requires synchronizing the shared state across cores, sometimes across NUMA nodes. That's slow. The same thing goes for mutexes. Modern, uncontended mutexes are very fast. But they can start sucking resources when you're locking them from multiple threads at the same time.
- benibela 6y ago
  >I was writing an interpreter using shared ptrs all over the place. I am doing that :/ In Object Pascal it is the standard memory management way. All strings and arrays are reference counted, and so I use it for all my own data structures as well I have not even added threading and I doubt I will, but the reference counting is already the slowest part Not sure what the alternative is
  - asdfasgasdgasdg 6y ago
    You can avoid reference counting overhead by using handles as described in this article. Each object in a slab would have just one reference, and you handles would be indexes into an array of them. Now, after you do that you will be on be hook for making sure you don't accidentally deallocate any of the objects that is currently in use. And it's not guaranteed to be faster. But it is one way to get around this issue.
    - benibela 6y ago
      I do not understand how this would help It would still need reference counting on the handles to know when the handle is not used anymore and the element in the array can be reused Without reusing handles it would surely run out of memory. Unless a full GC is used
- vvanders 6y ago
  Shared pointers also defer ownership decisions and lead to memory leaks via cycles which is its own very special level of hell.