Hi guys.Does anyone who studied the implementation of stringstreams know if :

char c;
   std::stringstream ss;

   ss << std::fstream ("file.xml",std::ios::in).rdbuf();//this is eqaul in terms of speed
  
   while (ss.get(c))  {} //with this?

   std::ifstream f("file.xml");
   while (f.get(c)) {} //or this?

Thanks a lot.

Dani AI

Generated

raised the right intuition: memory-backed access will usually beat repeated file-backed character reads. 's pointer to the stream buffer layer is correct, and is right that disk I/O is vastly slower than RAM — but the practical winner depends on how you transfer bytes into memory and what you do next.

Standard i/o is layered: formatted/unformatted calls on std::istream delegate to the underlying std::basic_streambuf methods (for example sgetn, sbumpc, sgetc), so per-character get() loops pay per-call overhead and can trigger buffer refills when the streambuf empties. See the standard streambuf documentation for details: basic_streambuf and basic_streambuf::sgetn.

A common fast pattern to load a whole file into memory in one go (avoids repeated reallocation and minimizes syscalls) is to open in binary mode, get the size, resize a std::string or vector, then read directly into that buffer:

std::ifstream in("file.xml", std::ios::binary | std::ios::ate);
if (in) {
    std::streamsize n = in.tellg();
    in.seekg(0);
    std::string s;
    s.resize(static_cast<size_t>(n));
    in.read(&s[0], n);
    // s now contains the file bytes
}

For concise alternatives, std::istreambuf_iterator<char> can construct a string directly (see istreambuf_iterator), but iterator-based approaches may be slightly slower than the sized read() idiom. Copying an entire stream via the streambuf layer is also efficient when transferring to another stream (see sgetn). For very large files or zero-copy needs consider OS memory-mapping (e.g., mmap) and always benchmark in release builds (turn off sync with C stdio via std::ios::sync_with_stdio(false) when comparing). See the read() reference: basic_istream::read and a short mmap reference: (https://man7.org/linux/man-pages/man2/mmap.2.html).

Recommended Answers

All 5 Replies

I don't understand the question. Are you asking if reading from a stringstream is faster than reading from an fstream?

I think i have several questions and a problem in how to put them.
1) Is the extraction operator using the get() function in case of fstream?
2) Does moving the file pointer imply another call to seekg()?
3) Would this mean stringstream's get() function would be faster?
4) Would this 'ss << std::fstream ("file.xml",std::ios::in).rdbuf();' be faster than both operations since the buffer is already filled?

I hope i'm not making a fool of myself :)

1) Is the extraction operator using the get() function in case of fstream?

Probably not. More likely is that it uses the member functions of the stream buffer directly (just like get()).

2) Does moving the file pointer imply another call to seekg()?

No, the file pointer is at a much lower level than seekg().

3) Would this mean stringstream's get() function would be faster?

It's fairly safe to assume that stringstream's get() function is faster, but that's because you're accessing strings in memory rather than hardware.

4) Would this 'ss << std::fstream ("file.xml",std::ios::in).rdbuf();' be faster than both operations since the buffer is already filled?

Well, obviously it comes down to the quality of the implementation, but writing the stream buffer is typically the fastest way to dump the contents of a stream.

Reading from a hard drive is typically around a million times slower than reading/writing to memory. I read that somewhere, don't quote me.

It would only make sense.Anyway after a bit more study i think the fastest possible way is by using the streambuf class methods directly or the i/ostringstream_iterators. I also could use someone's approval regarding that statement.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.