Thanks to both of you for useful responses. I hadn't thought of re-casting the char* into a struct. Wouldn't I have to add an extra char to the end of my struct because QByteArray::data() and QByteArray::constdata() both return null-terminated string?

Qt has some useful endian-conversion functions in QtEndian that I might be able to use after importing.

Quote Originally Posted by marcvanriet View Post
As a sidenote... I don't think that parsing such small chunks of data in a separate thread will speed up things. Possibly the effort of task switching is greater than the effort of parsing.
My reasoning was that it'd be faster to read a 30-byte (or 60-byte, or 190-byte... there's a handful of possible record formats) chunk from the disk and parsing that from memory instead of reading it 1-8 bytes at a time since HDD read/write tends to be very slow unless you have a SSD. Is that reasoning sound, or does Qt cache the file more than I realize? I've had issues trying to rapidly process a lot of data straight off the hard drive in the past—it tends to be many times slower than loading the whole file into memory first.

You make a good point about task switching, though... maybe I'll thread a couple thousand records at a time instead of one at a time.

I read in this thread that the system might run faster if I used the native int instead of the smaller integers. Supposing for a second that speed's more important than memory, would it be worthwhile to re-cast the records into a struct of native integers after importing? I guess there's only one way to really find out...