5 ms·
There's a ton of mandatory reference counting in almost every contemporary graphics driver. I also hate reference counting overhead, but it really isn't as big
by Jweb_Guru 4y ago
There's a ton of mandatory reference counting in almost every contemporary graphics driver. I also hate reference counting overhead, but it really isn't as big of a deal as you're making it out to be unless you use it for stuff like references in render passes.
- atwood22 4y agoThere's nothing wrong with reference counting. Manual reference counting using a technique like pointers into a generational array is fine. When the reference count goes to 0, release the generational memory. Any dangling pointers can handle the null value returned when trying to read the generational memory. That's a totally fine solution to reference counting. My issue is with automatic reference counting. It's just way too easy to hold on to a reference accidentally, especially now that lambdas / closures are an essential language feature. I don't have much Swift experience, but I do have a lot of Objective-C experience, and it's just way too easy to accidentally capture self or some other value. In game programming, there is very little concept of ownership. Everything exists as peers that can modify each other. This leads to a high likelihood of reference cycles.
- Jweb_Guru 4y agoI have not found in my own game programming experience that there's a whole lot of pointer soup, except in temporary scopes that can use stuff like arenas (indeed, this would be pretty terrible for performance) and there's usually a pretty clear ownership structure to be found (ownership may be muddled in a logical sense, but this isn't that relevant from a memory management perspective). Perhaps this is because I'm using a language that doesn't mandate reference counting though, so it's easy to do stuff like just build up temporary references into arrays etc. when necessary...