> You're ignoring real-world aspects of the problem.
No, I'm not. The most important real world aspect of this problem is that I can pull the complex part, the binary search, off the standard library shelf. All I need to implement is a random access iterator over the lines of an open file and I'm set.
> For example, you're assuming that the data points are evenly distributed across time
No, I'm not. I just don't care how they're distributed across times. 70GB is between 2^36 and 2^37 bytes. It's probably around 2^28 or 2^29 lines. Binary search over the characters would take at most 37 probes; over the lines it would take at most 29 probes. Since each probe is so cheap (one disk seek and one disk read, essentially) there's absolutely no reason to optimize any further, especially when I can use an off-the-shelf component like C++'s std::lower_bound to do my binary search for me.
> Reddit will most likely have regular busy and quiet periods, which will impact the density of the log at certain time
If you think that impacts the runtime of binary search at all, you've got a serious misconception about how binary search works.
> Thus, one can tune the algorithm to work better on Reddit's specific visitor pattern, if you can learn it.
Why bother? We're talking about a savings of milliseconds on an interactive process. An ordinary human like myself would never even notice the difference. The network lag from SSH alone would be greater than the difference in runtime.