Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am profiling the speed at which a certain Linux program reads a certain input file using different amount of threads by doing this:

time ~/src/myprogram -t $t inputfile 1>/dev/null 2>/dev/null

It seems like no matter what number of threads I use, starting from 12 down to 1, the time is exactly the same. Is there any other way to test this to make sure it is not influenced by the speed that data is sent to /dev/null?

share|improve this question

migrated from May 28 '13 at 14:07

This question came from our site for professional and enthusiast programmers.

I would look at your /src/myprogram rather than bash not doing what you think it is doing. /dev/null is a kernel device, I/O to it is as fast as I/O can get on your system. Please post your code if you want help. – jim mcnamara May 28 '13 at 12:32
Threads can only make code faster if it can spread CPU-bound operations across multiple cores. If your code is reading a file from disk, how are threads supposed to make it faster? – Mike Dunlavey May 28 '13 at 14:21
up vote 1 down vote accepted

The kernel caches I/O read from incoming block devices in free RAM. Unless your file is very large you are probably hitting the cached data in RAM and not actually causing any I/O.

A very quick search and reading this Stack Overflow answer reveals that this might do it:

sync && echo 1 > /proc/sys/vm/drop_caches

so I would try issuing those command before the command that performs the I/O.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .