C++ multimap causing slow program exit?

Question

I have a program that reads data from a .csv and creates a multimap. I've pasted a simple version below. It works fine, but runs really slowly on exit (i.e., once the program prints out the output and gets to return 0;. I'm working relatively big files, e.g., anywhere from 50 to a few hundred megabytes. The delay on exit is, unsurprisingly, proportional to the file size.

I'm wondering if there is any way to speed up the exit? My guess is that it's slow because it's clearing data from memory. CTRL+c in a terminal window shuts it down immediately, though. I've looked but haven't found much.

#include <iostream>
#include <sstream>
#include <fstream>
#include <string>
#include <vector>
#include <map>

int main (int argc, char* argv[])
{

std::string filename = "edge_data_mid.csv";

// obtain multimaps
std::ifstream fin;

fin.open(filename.c_str(), std::ios_base::in|std::ios_base::binary);
if (!fin.is_open()) {
    std::cout << "could not open the file '" << filename << "'" << std::endl;
    exit(EXIT_FAILURE);
}

std::multimap<std::string, std::string> gciting;

std::string line;

// this loop parses the file one line at a time
while (getline(fin, line)) {
    std::istringstream linestream(line);
    std::string item;

    std::string nodea;
    std::string nodeb;

    getline(linestream, item, ',');
    nodea = item;
    getline(linestream, item);
    nodeb = item;

    gciting.insert(std::pair<std::string, std::string>(nodeb, nodea));
}

fin.close();       

std::cout << gciting.count("3800035") << std::endl;

return 0;
}

Answer 1

Yes, destructors for std containers take a while if they manage memory (in your case, they do manage the memory of the std::strings they contain) and they contain a lot of elements.

If you don't mind the memory leak (which is not a leak per-say, since it isn't leaking continuously and it's controlled), you can allocate the map dynamically and forget to delete it:

std::multimap<std::string, std::string>* gciting = new std::multimap<std::string, std::string>;

std::string line;

// this loop parses the file one line at a time
while (getline(fin, line)) {
    std::istringstream linestream(line);
    std::string item;

    std::string nodea;
    std::string nodeb;

    getline(linestream, item, ',');
    nodea = item;
    getline(linestream, item);
    nodeb = item;

    gciting->insert(std::pair<std::string, std::string>(nodeb, nodea));
}

fin.close();       

std::cout << gciting->count("3800035") << std::endl;

//oooops forgot to delte gciting
return 0;
}

Answer 2

How would I make my object not to be destructed?

If you really want to stop the object from deallocating itself and it's containing elements (since you know the application will terminate) you could allocate it on the heap using new and then never free the memory (normally done through delete).

This normally isn't recommended but major operating-systems today are smart enough to release any allocated memory back to the OS when an application terminates, so you should be safe by using this approach.

---

Please note that I used the word "should" and not "will" in the above.

There is nothing in the standard saying that the memory allocated will be released back to the OS or what will happen if you don't release it (other than that you have leakage).

If you are writing code to be run on a minor system (such as the controller of a fridge), do not use this approach before actually verifying that this platform will indeed free memory after termination.

We don't want our food to go bad.

---

Potential reasons for it being slow besides memory deallocation

If you are running your application in debug mode a lot more than what is required to happen will take place to aid eventual debugging of your application.

Try compiling it with optimization flags turned on, and in (what is normally referred to as) release mode.

---

Using placement new..

If you, for some odd reason, still want your object to reside on the stack you could make use of placement-new, as in the below snippet. placement-new will try to make use of the address you pass to it and put the object there.

c++11

#include <type_traits>

typedef std::multimap<std::string,std::string> SSMap;

std::aligned_storage<
  sizeof(SSMap), std::alignment_of<SSMap>::value
>::type storage;

SSMap& gciting = * new (&storage) SSMap;

/* use gciting exactly as before */

---

c++03

In C++03 the best/easiest way to ensure proper alignment is to use malloc to allocate memory which will meet the strictest alignment available (that will work for every type).

With this said there is no easy way of having the object still residing on the stack, though the interface of which to use the object stays the same, we can still create a reference to an object residing on the heap.

#include <cstdlib>

typedef std::multimap<std::string,std::string> SSMap;

char * storage = static_cast<char*> (std::malloc (sizeof (SSMap))); 
SSMap& gciting = *new (storage) SSMap;

/* use gciting exactly as before */