Thanks Robert. I left the declaration of the static variables outside the function because local static variables aren't thread safe: http://blogs.msdn.com/b/oldnewthing/archive/2004/03/08/85901.aspx Could putting the static variables in an anonymous namespace avoid the issues with static builds?
On 25 November 2010 12:32, Robert Osfield <[email protected]> wrote: > Hi Michael, > > Changes look good. The unique ID manager is very simple and nicely > hidden away as an implementation detail. The only tweaks I made were > to remove the use of the assert() and to place the static variables > into the getNameID() method to prevent issues when doing static > builds. Changes now checked into svn/trunk. > > Cheers, > Robert. > > On Tue, Nov 23, 2010 at 4:36 PM, Michael Platings <[email protected]> > wrote: > > Hi Robert, > > I agree and the attached files implement your suggestion. > > The name-to-id manager is very simple so I've implemented it as part of > > Uniform. If it becomes useful for other classes then it can be moved out > > easily enough, but for now I'm assuming YAGNI :) > > I wouldn't like to assume that the global number of uniform names will > > remain small enough that a vector of uniform locations per-Program would > be > > preferable to a map, so I've left that as a map for now. > > Cheers > > -Michael > > > > On 23 November 2010 10:42, Robert Osfield <[email protected]> > wrote: > >> > >> Hi Michael, > >> > >> I think a unique NameID would be better than a hash. I had a previous > >> submission that I recall went the ID approach but it wasn't thread > >> safe so wasn't merge-able as it was. > >> > >> What would be need is a thread safe singleton for managing name to ID > >> mappings. Uniforms and other classes could potentially use this. > >> Another possibility is if we could cluster the ID's close enough in > >> each Program then it might be possible to use an std::vector<> rather > >> than a std::map for the look up and then just use the ID as the vector > >> index. > >> > >> Thoughts? > >> Robert. > >> > >> On Fri, Nov 19, 2010 at 7:44 PM, Michael Platings <[email protected]> > >> wrote: > >> > Hi Robert, > >> > I've found that as I'm using more uniforms in my app, the cull time > has > >> > increased significantly. On investigating this, I discovered that lots > >> > of > >> > string comparisons were being done in getUniformLocation(). A simple > >> > method > >> > that speeds this up dramatically is to store hashes of the uniform > names > >> > and > >> > compare them rather than the names themselves. > >> > I've implemented this, and attached the files. > >> > It's not perfect though, there is a small chance that two uniform > names > >> > will > >> > have the same hash. However that's unlikely to happen unless you've > got > >> > thousands of different uniform names. Maybe it would be worth using a > >> > more > >> > complex hash (I've used djb2) or 64 bit numbers - I'll be interested > to > >> > hear your thoughts. > >> > Thanks > >> > -Michael > >> > > >> > _______________________________________________ > >> > 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
