Dirk Reiners wrote: > Hi Allen, > > Allen Bierbaum wrote: >> [...] >>> I've profiled our app and 10% of the time in OSG-dlls is spent in >>> GetAspect(). That's quite a bit and therefore I'm happy to see >>> c-pointers being introduced in C++. Hopefully, it will also reduce >>> compile times & code size. (No more copy-ctoring of FCPtrs everywhere). >> Did your profiling separate application level use from internal use? > > I did some benchmarks with my little python benchmark wrapper, and I got > to similar results (~10% in getAspect), and on that one the whole > application loop was "setCamera(); win->render();". So my guess would be > most of the time is internal. > > Nonetheless I'm not sure what the problem is. If you have an app that > needs thread-sage pointer transfer, just use MTRefPtr for variable > storage and if you need a tight loop or copy things around use a normal > Ptr (or RefPtr, if needed). > >> I >> agree that the current ptr's have too much overhead to use in >> performance critical sections of the internal code, but my assumption >> was/is that if an application (whether C++ or python based) uses >> aspect-safe RefPtr's that this overhead is minimal compared to the time >> spent on rendering, traversal, and all other things internal. >> >> I don't have any numbers to back this up though so I could be wrong. :) > > It all depends on what you consider minimal. ;) 10% is not like a > hotspot, but IMHO too much to be called minimal.
But as you point out, that 10% time is spent internal to OpenSG. What I am saying is that the amount of user calls per frame that will deref a pointer is going to be dwarfed by the calls OpenSG does internally. So my guess is that the overhead of getAspect in user code will end up as an infinitesimal blip on the performance profile. To be clear, I do agree that OpenSG should be using Ptrs and cptrs internally. I am only talking about the user-level API that is used in the users' applications. -Allen > > Dirk > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Opensg-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensg-users > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
