Hello Aron,
Aron Bierbaum wrote:
> I have found that, while slow, the FieldContainerFactory
> seems to leak memory.
personally I would not call it a leak, but that is more of a
philosophical point ;) (I understand that it can be a problem).
> The issue is that the _vContainerStore grows
> without bounds. Each time a field container is created a new pointer
> is pushed onto the deque, and when the field container is destroyed
> the pointer is only set to NULL. This results in a substantial memory
> growth in our test case. For example the following metrics were taken
> (allocated fcs / total fcs).
yes, that is the case and it is kind of known but generally ignored - it
has come up a few times in the past when people were investigating
memory consumption but in the end it never seemed a big enough issue to
seriously investigate/profile alternatives.
> Does this make sense that we are losing memory at this location? And
> if we are what ideas do people have to fix this? My first naive
> approach would be to search for the first entry with a NULL value, but
> this will probably be much slower than we would want. I don't think
> that we can erase the entries because the index is used as the field
> container ID. Another idea would be to keep a vector of available
> empty slots that could be used when creating a new field container.
it is not so much about reusing the empty slots, but the store is also
used as a map from id to container so you need to be able to return the
correct pointer given a container id. You should also be able to do so
fast as this is used in a couple of places (cluster sync being one of them).
In response to a similar question I once wrote a patch that switched the
factory to use a std::map (it was for 1.x though, should be in the ML
archives somewhere). In order to not risk a big drop in performance I'd
look into using a (boost::/std::tr1::) unordered_map - the biggest issue
with those is that I'm not sure about tr1 support across platforms and
boost added the unordered lib in 1.36 and many linux distros only rather
recently switched from 1.35 to 1.37.
Cheers,
Carsten
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
