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. :(
Dirk
------------------------------------------------------------------------------
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
