Hi Tim, On Thu, 21 Jun 2018 at 08:25, Tim Moore <timoor...@gmail.com> wrote:
> Before you move on, the big advantage of std::shared_ptr over intrusive > reference counting is that support for weak pointers is rock solid. In the > intrusive model, you can't implement thread-safe weak pointers without an > auxiliary data structure, which complicates the implementation a lot. I > know that one historic OSG performance win for osg::ref_ptr was the > ability to not do the reference counting if it isn't needed, but with > atomic increment / decrement implemented everywhere, do you think there is > really much performance advantage for intrusive counting? Also, > std::make_shared<>() allocates the shared_ptr control block in the same > memory allocation as the shared object, so there need not be a memory > fragmentation hit for using shared_ptr. > >> The big advantage of intrusive reference counting is that the ref_ptr<> holds a pointer to the actual object that you want to access, it's a single jump. shared_ptr<> is literary a pointer to a shared pointer (which is a reference counted object) to a the actual object that you want to access, it's two pointers, two objects vs one pointer and one object. Scene graphs are predominately memory bandwidth limited so this extra level of indirection is not even close to as efficient as intrusive reference counting. The only advantage that shared_ptr<> has is that it works with any type, but with a scene graph the types are mostly all under our control there is no cost in complexity of having intrusive reference counting, just stick it into the base class that most classes use anyway and your job is done. So... as my aim where possible is to make the VulkanSceneGraph more efficient than the OpenSceneGraph I can't just put chains around my ankles by adopting shared_ptr<>, instead I will acknowledge where the OpenSceneGraph already does something well and following this approach, albeit in a modern C++ way. For the thread safe observer_ptr<> you do need a separate auxiliary object, just like the OSG, so in my prototyping this is already what I have done. I already have an vsg::Auxiliary object that is created when required, this Auxiliary object is for more than just supporting observer_ptr<> though, it also stores optional extra user data. Doing this shrinks the base vsg::Object/Node classes and improves memory utilization, providing a measurable gain in construction, destruction and traversal of the scene graph over what can be done with the OSG. When adopting new features of C++ you have to understand what is happening under the hood, for software that is performance critical like a scene graph you have to take the time to make sure there aren't hidden performance costs are, if there is a cost then you have to be really sure that this cost is worth the value it provides. shared_ptr<>/weak_ptr<> don't cut it for the core scene graph. There are plenty of other modern C++ features that are really neat and just make life easier without a cost, you'll see this sprinkled everywhere in the VulkanSceneGraph. Cheers, Robert.
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
