What impacts 'perceived' performance:
If you are running something, like an editor, and you hit a key and there is a wait for the screen to display it, that's a perceived performance hit. The performance may only be degraded by .5 second.
On the other hand, if you're printing a file and the same thing happens to the spooler (the process that prints for you like winspool) you would never notice.
So, two things that slow down your perceived performance are:
I/O bound - your process is competing for the same files as another process
or you have to wait for another process to complete it's I/O request.
CPU bound - you have to wait for the other guy to release the cpu to get
your share.
I/O bound is probably what you are experiencing. You can be I/O bound and have low cpu usage. I/O bound is related to I/O queue request length.
Like being in a line 5 people behind the head of the ATM line. When you get your money, you go to the end of the line to wait to get more money. The longer the line the longer the wait.
There is no 'most reliable' way. User perception varies depending on what they expect. If a user starts a job that last 30 minutes and it completes in 33 minutes they probably won't care because they went to get lunch anyway.
If the user is entering data and he has a perceptible delay in screen update after a keystroke -say .2 seconds, he'll complain. If the overnight batch run grinds on until 10:00am everybody will scream loudly, including your boss.
That is a huge performance hit.
Performance is in the eye of the beholder. If you want a metric look up Dhrystone. That is, performance suites that measure raw power. Real performance is what the user sees/(does not see) under normal (whatever that is)load.