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;
}
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.
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.
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.
#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 */
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 */