Simplify sha256sum Streambuffer example
Simplify sha256sum Streambuffer example

It turns out, mmapping instead of buffered reading can make a
significant difference, when the files are cold and when the files are
hot. Still, trying to do this async is probably not worth the effort:

 * The ideal case is where a program spends just as much time doing IO
   as it does doing computations. In that case IO and computation can be
   done in parallel (as opposed to interleaved, which you get with
   blocking IO), and you get double the performance.

 * In a not-so-ideal case, say 90% compute and 10% IO or 90% IO and 10%
   compute, the 90% is still the bottleneck, so even by parallelising IO
   and compute, there is at best an 11% win.

 * The computation depends on the data, so not only do they have to
   match in volume, the data also has to be available at the right time.

 * It is tricky to supply data fast enough. Perhaps a good strategy
   would be to preload for a while and then start compute, timing it
   such that the last loads comes at the moment that the computation
   needs it. This requires a special setup; there is no "steady state"
   that the program spends most time in.

 * Instead of bothering with task queues and whatnot, if prefetching
   helps, then it is probably sufficient to just loop and prefetch the
   next file at every iteration. Any extra complexity is likely not
   going to perform any better.

My current experience is that the kernel is quite good at guessing what
to prefetch even without the `madvise` hints, and on the other hand, if
the program is IO-bound, then no amount of `madvice` is going to help;
you run at IO speed.

Still, it was nice to have the `resident_len()` method and see the
prefecting strategy of the kernel in action.

ruuda/filebuffer,ruud-v-a/filebuffer