Hi Robert, I don't think the macro would help in this case, because the stream handle is being passed to the State::print() function, which then unconditionally writes to it. Checking the current severity level before calling the print function is probably the best solution, performance-wise. Didn't know about the CMake option, thanks for that!
Cheers, Farshid On Tue, Apr 9, 2013 at 12:46 PM, Robert Osfield <[email protected]>wrote: > Hi Farshid, > > Thanks for the details. We now have an OSG_INFO macro that has an if () > statement before the stream operator to help avoid this big cost. I haven't > looked at the code by I guess it probably doesn't use this for some > reason. You can actually disable the use of notify using CMake and the > macros as well so they compile to a non op, something useful for > applications that never need notification support such as a distributed GUI > application. > > Robert. > > > On 9 April 2013 20:42, Farshid Lashkari <[email protected]> wrote: > >> Hi Robert, >> >> Yes, I'm on Windows. I vaguely recalled there being performance issues >> with the notify streams on Windows, so that gave me a hunch that the >> logging might be causing the issue. The performance drop was occurring with >> the default NOTICE severity level, so nothing was actually being printed >> out. Setting the notify level to INFO completely kills performance (70x >> increase). I would even suggest lowering the logging level for that >> information to DEBUG_INFO. >> >> Cheers, >> Farshid >> >> >> >> >> On Tue, Apr 9, 2013 at 12:32 PM, Robert Osfield <[email protected] >> > wrote: >> >>> Hi Farsid, >>> >>> Thanks for the change. Once I get back to merging submissions I'll be >>> able to tackle this. >>> >>> Any chance you are working under Windows? I don't see these performance >>> drops under Linux so sometimes don't spot problems like this. Windows >>> implementation of the ostream to null is a real mess w.r.t performance. Do >>> you see the performance issue only when INFO is on? >>> >>> Robert. >>> >>> >>> On 9 April 2013 19:12, Farshid Lashkari <[email protected]> wrote: >>> >>>> Hi Robert, >>>> >>>> I just started looking into the shader composition feature. I enabled >>>> shader composition on the osg::State object and noticed a 6x increase in >>>> draw time. I figured that the default composer might have performance >>>> issues, so I created a custom ShaderComposer that overrides >>>> "getOrCreateProgram" and does nothing. This still resulted in a performance >>>> drop. >>>> >>>> I looked into the "State::applyShaderComposition" method and noticed >>>> that it will print debug information to the osg::INFO stream. I commented >>>> that line out and the performance drop was gone. >>>> >>>> I'm not sure if the printing was accidentally left in or is meant to be >>>> enabled. I've modified the function to only call the print function if INFO >>>> logging is enabled. I've attached the change. >>>> >>>> Cheers, >>>> Farshid >>>> >>>> _______________________________________________ >>>> osg-submissions mailing list >>>> [email protected] >>>> >>>> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >>>> >>>> >>> >>> _______________________________________________ >>> osg-submissions mailing list >>> [email protected] >>> >>> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >>> >>> >> >> _______________________________________________ >> osg-submissions mailing list >> [email protected] >> >> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >> >> > > _______________________________________________ > osg-submissions mailing list > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > >
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
