Thread: memory problems with map(), need an urgent reply

Well, perhaps it would be clearer if you wrote:

Code:

for (;;)
{
    map<string, bool> myMap;
    string temp;
    for (int i = 0; i <= 5000; ++i)
    {
        temp.append(1, i);
        myMap[temp] = true;
    }
    cout << "Entering" << endl;
}

If you create a new map (or clear an old one) and then add an element with an index of 5000, or 10000, or 15000, you now have a 5000/10000/15000 element list. That's what you are doing with temp.

Originally Posted by MK27

If you create a new map (or clear an old one) and then add an element with an index of 5000, or 10000, or 15000, you now have a 5000/10000/15000 element list.

That is not the case.

Only thing I can think of is that map doesn't want to let go of the memory it allocated just in case you might use it again later. It's probably using some type of lazy implementation where it only releases memory when it absolutely has to. I think it does something similar for allocation in that it will not allocate a new chunk until it has to.

I have also seen map memory grow to enormous sizes and it never wants to let go of it. Some time back I was tasked with figuring out something very similar. My only conclusion was that it was very hard to determine how much memory a given map would require at any one time. I had very simple code much like yours and then checked the memory via API calls. I could not find a consistent behavior except in allocation. Map would allocate a sizeable chunk and once that was filled it would then allocate another sizeable chunk. The allocation scheme for the STL is predictable and constant but I could never figure out deallocation. Perhaps other more knowledgeable members here can fill in the gaps. I will check Effective STL to see if I can find anything useful.

Because of my experiences with map I normally opt to use pointers inside of them so that on removal I can manually delete and manually erase the object from the container. Ostringstream appears to have this same type of behavior. If you do not allow ostringstream to go out of scope or manually clear it via .str("") it will continually eat memory.

Originally Posted by Bubba

Only thing I can think of is that map doesn't want to let go of the memory it allocated just in case you might use it again later. It's probably using some type of lazy implementation where it only releases memory when it absolutely has to. I think it does something similar for allocation in that it will not allocate a new chunk until it has to.

That is what I suspected at first (I was about to suggest the swap with a default constructed temporary trick), but then that should mean that on the next round, the already allocated space would have been used.

The problem is probably just due to the unlimited appending to temp that my example fixes (or not, as tabstop noted).

Originally Posted by laserlight

That is not the case.

No, I suppose not -- it's a map, not an indexed array. At first glance I assumed temp was an int, not a string.