Are you implying that I am lying? That I could not have seen what I already said I did?
FYI just before I went to bed last I decided to google this exact subject, and I ran across http://kerneltrap.org/node/452. The point that was made there about kernels of the same vintage as the ones that I was working with was, The current readahead model is per-inode, which is very little help with lots of small files, especially if they are fragmented or out of order.
This is extremely relevant because I was working with small files of exactly that kind. If readahead works for you then latencies do not matter because the next piece of data you want has always been fetched for you before you asked for it. But if readahead does not work for you, then you will wind up waiting for the round trip time between when requests are sent to disk and the disk responds to you.
So your comments about throughput are based on an assumption of a situation where the OS is able to anticipate your future requests before you make them, while my comments about latencies are based on an assumption that it is not. Your assumption is more likely to be true today. Mine certainly was true for me in the situation where I last cared to benchmark this.
In reply to Re^9: Algorithm advice sought for seaching through GB's of text (email) files
by tilly
in thread Algorithm advice sought for seaching through GB's of text (email) files
by chargrill
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |