Hi, On Mon, 2011-02-07 at 17:11 -0600, Dirk Reiners wrote: > Hi Carsten, > > On 02/07/2011 04:07 PM, Carsten Neumann wrote: > > > > hmm, not sure about that, we still have the vector (well, it's a > > std::deque<>), but that does not make much of a difference for the > > amount of memory, only that it does not require a large _contiguous_ > > chunk of memory... > > I haven't looked at the implementation, but given that all the objects are > destroyed I would that it frees empty blocks. > > > I think the biggest obstacle in changing this is the disaster that is > > trying to get a hash_map/unordered_map implementation on the common > > platforms. We could use boost::unordered_map, but that only made it into > > boost 1.36, RHEL 5 comes with 1.33 AFAIK :-/ > > Hm, that might be a problem, given that RHEL 5 will probably be with us fora > while. Not sure what the best solution would be. :(
if these are only headers and one can use the 1.36 version with the rest of 1.33 (have not tried it) put it into Source/External and include it from there on these platforms. We do this with the google hash_map implementation and I pulled the circular buffers from a later boost version within the complex scene manager. kind regards gerrit ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
