Unfortunately, std::map doesn't sit in memory in one large chunk - there
is one chunk for each entry in the map, so there is no way to write out
the map without iterating over the entries.

 Now your suggestion goes reading one record at a time...

I'm sure it is possible to reduce the time further. One approach is to
remove the calls to "read" and "write" and replace them with calls like
this:

FileOut.rdbuf()->sputn(same params as for write);

FileIn.rdbuf()->sgetn(same params as for read);

sputn/sgetn are quite a bit faster than write/read.

Another approach is to take the map and transfer its contents to a
vector, which can be written out in one chunk. I've posted two different
approaches, one legal but a bit slower, the other illegal, but likely to
work on most platforms:

typedef map<int, double> IMAP;

struct IMAP_POD
{
    int key;
    double value;
};

struct IMAPConverter
{
    IMAP_POD operator()(IMAP::const_reference val) const
    {
        IMAP_POD p = {val.first, val.second};
        return p;
    }

    std::pair<int, double> operator()(IMAP_POD const& val) const
    {
        return std::pair<int, double>(val.key, val.value);
    }
};

void writeIMAP(IMAP const& m, ostream& os)
{
    vector<IMAP_POD> v(m.size());
    transform(m.begin(), m.end(), v.begin(), IMAPConverter());
    //write the size:
    vector<IMAP_POD>::size_type size = v.size();
    os.write(reinterpret_cast<char*>(&size), sizeof size);
    //write the map as a single vector:
    os.write(reinterpret_cast<char*>(&v[0]), v.size() * sizeof v[0]);
}

void readIMAP(IMAP& m, istream& is)
{
    vector<IMAP_POD>::size_type size;
    //read the size:
    is.read(reinterpret_cast<char*>(&size), sizeof size);
    vector<IMAP_POD> v(size);
    //read the map as a single vector:
    is.read(reinterpret_cast<char*>(&v[0]), v.size() * sizeof v[0]);
    vector<std::pair<int, double> > typedV;
    typedV.reserve(size);
    transform(v.begin(), v.end(), back_inserter(typedV), IMAPConverter());
    //range insert for a sorted range
    //is much faster than inserting one by one
    m.insert(typedV.begin(), typedV.end());
}

Illegal approach:

typedef map<int, double> IMAP;

void writeIMAP(IMAP const& m, ostream& os)
{
    typedef std::pair<int, double> non_const_value_type;
    vector<non_const_value_type> v;
    v.reserve(m.size());
    v.insert(v.begin(), m.begin(), m.end());
    //write the size:
    vector<non_const_value_type>::size_type size = v.size();
    os.write(reinterpret_cast<char*>(&size), sizeof size);
    //write the map as a single vector:
    os.write(reinterpret_cast<char*>(&v[0]), v.size() * sizeof v[0]);
}

void readIMAP(IMAP& m, istream& is)
{
    typedef std::pair<int, double> non_const_value_type;
    vector<non_const_value_type>::size_type size;
    //read the size:
    is.read(reinterpret_cast<char*>(&size), sizeof size);
    vector<non_const_value_type> v(size);
    //read the map as a single vector:
    is.read(reinterpret_cast<char*>(&v[0]), v.size() * sizeof v[0]);
    m.insert(v.begin(), v.end());
}

The reason that is illegal is that you can only copy the bytes into and
out of POD types, and std::pair<int, double> is not a POD type. However,
pair<int, double> is close to being a POD type (it doesn't have any base
classes or virtual functions, and the destructor is basically a no-op),
so the above is very likely to work on every platform.

The problem here is the format used by the CPU and compiler to hold ints
and doubles, and the sizes of those types. For example, some CPUs use a
big endian 64-bit 2s complement format for "int", while Windows (and
UNIX) compilers for x86 use a little endian 32-bit 2s-complement format.
Basically, the bits for a particular int value (such as 1234567) are
quite different on some platforms.

There's a bit more on it here:
http://www.eskimo.com/~scs/C-faq/q20.5.html

If you want portable binary, you need to decide on exactly the binary
format you want, and then make sure that your code writes out bytes in
the right format (byte-order swapping and padding as necessary).

 I thought

It should be possible to optimize the code you use to read it as text so
that it operates much faster. If you need portability, this may be the
best option. If you want to do this, I'd suggest posting the code you
have (in a new thread) and asking for help in speeding it up.

Tom