On 2010-02-18 18:03, Carsten Neumann wrote: > 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.
Both gcc and msvc had hash_map implementations back in 2000/2001, in the stdext namespace (for msvc) and somewhere else on gcc. Those could also be used for backwards compatibility. Cheers, /Marcus ------------------------------------------------------------------------------ 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
