c++ Reading the first few bytes out of every X bytes efficiently - c++

Question

I want to read the first 16 bytes out of every X*16 bytes of a file. The code I wrote works, but is quite slow, because of many function calls.
std::vector<Vertex> readFile(int maxVertexCount) {
std::ifstream in = std::ifstream(fileName, std::ios::binary);
in.seekg(0, in.end);
int fileLength = in.tellg();
int vertexCount = fileLength / 16;
int stepSize = std::max(1, vertexCount / maxVertexCount);
std::vector<Vertex> vertices;
vertices.reserve(vertexCount / stepSize);
for (int i = 0; i < vertexCount; i += stepSize) {
in.seekg(i * 16, in.beg);
char bytes[16];
in.read(bytes, 16);
vertices.push_back(Vertex(bytes));
}
in.close();
}
Could someone give me some suggestions to increase the performance of this code?

Answer 1

Don't use seek, I would mmap this whole file and then simply read off the bytes at the desired locations.
I'm not going to write the code for you, but it should be along the lines of:
Open the file, calculate the file size
mmap the whole file
Iterate through in your step sizes calculating the address of each block
Construct each Vertex based on the block and push into the vector
return the vector.

Answer 2

It's likely not the function calls itself, but the non-sequential access pattern, picking small segments from a large file. Even though you are reading only 16 bytes, the storage subsystem likely read (and caches) larger blocks. Your access pattern is deadly for typical I/O.
(Profiling should show whether disk access is the bottle neck. If it was "many function calls", CPU would be.)
So, first and foremost, can you change this requirement?
This is in all scenarios the easiest way out.
Could you scatter less? E.g. instead of reading vertices 0, 20, 40, ..., 1000 , read vertices 0,1,2,3,4, 100, 101, 102, 103, 104, 200, 201, 202, 203, 204, ... - same number of vertices, from "all parts" of the file.
Second, OS specific optimizations.
There's no portable way to control OS level caching.
One solution is memory mapping the file (CreaterFileMapping on Windows, mmap on Linuxy systems), as suggested by #Nim. This can omit one memory copy, but still the entire file will be read.
Can't help much with Linux, but on Windows you have as parameters to CreateFile:
FILE_FLAG_NO_BUFFERING which basically means you do the buffering, giving you finer control over the caching that happens, but you can't seek + read willy-nilly.
FILE_FLAG_SEQUENTIAL_SCAN which just telsl the cache not to store old data
Neither of these will solve the problem with your access pattern, but the first may mediate it somewhat - especially if your steps are larger than disk sectors, and the second can take pressure from the subsystem.
Third, Snapshot.
The best option may be to store an interleaved snapshot either in an associated file.
The snapshot could simply be the result of your operation, for a particular maxVertexCount. Or multiple snapshots, like mipmapping. The idea is to replace the scattered read by a sequential read.
Alternatively, the snapshot can store the data in interleaved order. For 128 vertices, you could store vertices in that order (roughly, beware of off-by<-one, zero-vs-one-based and aliasing effects, and my mistakes):
64, 32, 96, 16, 48, 80, 112 8, 24, 40, 56, 72, 88, 104, 120 ...
Whether you read the first 3 or first 7 or first 15 or first 31... values, the samples are equally spread out across the file, like in your original code. Rearranging them in memory will be much faster - especially if it's just a small subset.
Note: you need a robust algorithm to detect that your snapshot is out of date, independent of the many funny things that happen with "last write date" on different file systems. A "change counter" in the main file would be the safest one (though it would icnrease the cost of changes).
Fourth, Change the file format
(In case you can control that)
The interleaved storage suggested above could be used for the entire file. However, this has big implications for processing - especially if you need to restore the "original" order at some point.
An elegant option would be having such an interleaved subset as part of the file, and the full list of vertices in original order. There is a cutoff stepSize where this doesn't help much anymore, probably around 2*sector/block size of the disk. So file size would increase only by a few percent. However, writes would get a little more costly, changes to the amount of vertices significantly worse.
Aliasing warning
If this is intended to get a "statistical" or "visually sufficient" sampling, a fixed stepSize might be problematic, since it can create aliasing effects (think Moire patterns) with any patterns present in the data.
In this case, a random sampling would be preferrable. That may sound scary and makes some of the solutions above a bit harder, but is often the easiest way to avoid many suboptimal cases.

Answer 3

... and if for some reason you can't use map, read the file into a buffer in "great big gulps" ... a buffer-size that is some multiple of X bytes. Continue reading into that buffer (taking care to notice how many bytes were read). until you reach the end of the file.
What you're specifically trying to avoid is a whole bunch of physical I/O operations: movement of the disk's read/write mechanism. The operating system likes to buffer things for this reason but it can only guess at what your application is trying to do and it might guess wrong. Once the disk has positioned the read/write head to the proper track ("seek time"), it can retrieve a whole track's worth of data in one rotation. But "seek time" is comparatively slow.
Mapping the file, and then reading the data in the mapped file non-randomly, is clearly the most favorable strategy because now the operating system knows exactly what's going on.

Answer 4

First, I assme you're returning the vector by value from the definition even though your posted code lacks a return statement, so the vector has to be copied. Pass it by reference into your method so no copying is needed.
And you can use low-level pread() to read without needing to seek:
void readFile( size_t maxVertexCount, std::vector<Vertex> &vertices )
{
struct stat sb;
int fd = std::open( fileName, O_RDONLY );
std::fstat( fd, &sb );
size_t vertexCount = sb.st_size / 16;
size_t stepSize = std::max( 1, vertexCount / maxVertexCount );
vertices.reserve( vertexCount / stepSize );
for ( off_t i = 0; i < vertexCount; i += stepSize)
{
char bytes[ 16 ];
std::pread( fd, bytes, 16, 16 * i );
vertices.push_back( Vertex( bytes ) );
}
std::close( fd );
}
You should be able to figure out the required error handling and header files.
This takes advantage of the kernel's page cache and likely read-ahead. Depending on your OS and configuration, other methods such as mmap() or reading the entire file may or may not be faster.