Hi Robert, Thanks for the response.
> We'll if VisualStudio's debug performance is too bad to develop with > routinely avoid using debug unless you actually need to do debugging, > or pick a better compiler or see if you can tweak compiler options to > avoid the pitfalls of VisualStudio. > > I do plan to try some compiler options. Although, if others have had similar experiences, then I can reduce the amount of time I spin my wheels so to speak. > Personally in dev work I just use an optimized build, then perhaps a > couple of times a month I might come across an issue that really needs > a stack trace or a putting a break point into to monitor something and > I will do a debug build. A will often go several weeks on the trot > without ever using debug. This is even under Linux where the gcc > compiler can do debug builds without totally killing performance. > > Unfortunately, this isn't an option for us. I feel that we're diverging from what I think is most perplexing about what I'm seeing. When I restrict the process to use less cores, I get increased rendering performance. This is what leads me to believe there are some load-balancing issues. Also, if I have the OSG process set to both cores and I run another single-threaded process in the background, the other process gets assigned to one core, and OSG rendering speeds up, presumably because it is being processed mainly on a single core. I've been playing with the OSG threading models as well. In debug, SingleThreaded mode seems to run the best on my machine. Is there documentation on the implications of the threading models? If I understand correctly, "SingleThreaded" means only the rendering is single threaded, and the database pager is still a separate thread. Is this right? Are reasons we shouldn't consider using SingleThreaded mode? Thanks, Jesse
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
