<div dir="ltr">On Thu, 21 Jun 2018 at 12:11, Tim Moore <<a href="mailto:timoore33@gmail.com">timoore33@gmail.com</a>> wrote:<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>This is not the way shared_ptr is implemented, at least in gcc. The shared pointer contains a pointer to the object as well as to the control block. You could argue that this makes a shared_ptr twice the size of an osg::ref_ptr, but I really can't speculate on the overall effect on memory usage.</div></div></div></div></blockquote><div><br></div><div>16 bytes instead of 8 for every single pointer... plus the extra shared pointer object... is it just a pointer + atomic?</div><div><br></div><div>shared_ptr<> is a "solution" to how do I share types like an int, but it's not at a good solution for situations where intrusive reference counting is trivial to provide as part of class design.  <br></div><div><br></div><div>Intrusive reference counting is a far better solution for a scene graph, there isn't a comparison.  Frankly I can't believe I'm even having to explain this, shared_ptr<> is a niche solution that gets way more airtime than is deserves.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div>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.</div><div><br></div><div>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.<br></div></div></div></blockquote><div>What's the measured gain? </div></div></div></div></blockquote><div><br></div><div>Measurable gain as in timing stats, the approach I'm exploring for the VulkanSceneGraph is faster for creating objects, destructing objects and traversal.  Good for all users, especially any time we are paging data.  <br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Of course I trust your judgement, but I struggled mightily with weak pointer thread safety back in the day and am happy to be able to make it someone else's problem now. I am very happy that VulkanSceneGraph is coming on the scene!</div></div></div></div></blockquote><div><br></div><div>I remember all the pain getting is to work robustly.  My experiments build upon what the OSG does currently, but using std::atomic, as well as discarding a lot of baggage that the OSG has due to it's long history, it's far, far cleaner. Yes we'll hammering with mutti-threaded stress cases to make sure what we end up with is solid implementation, but with the implementation being so much cleaner I expect the process to be a lot less painful.</div><div><br></div><div>Things like ref_ptr<>/observer_ptr<> are just a tiny bit of what I'm looking at in the Exploration Phase, these are really just a footnote compared to the wider design and implementation issues.<br></div><div><br></div><div>Robert.<br></div></div></div>