One point that has not been addressed yet is your suggestion that simple operations should always be performed first:

if ( -s $file || $file =~ /\.new$/ || $file eq 'foo ') { ;}

Was not write in the best way! First, the -s need to be the last, because we can avoid the query in the HD. the eq need to be the first, since is more easy to process than a regexp.

If all of the component expressions fail, all component expressions will be executed, therefore, for the purpose of the failure case, the order of the component expressions does not matter.

The only way of optimizing the above code fragment is to optimize for success. Given an input of 20 file names, what percentage of them will equal 'foo', what percentage of them will end with '.new', and what percentage of them will be empty?'

If 50% of them end with '.new', 0% or 5% of them equal 'foo' (0 or 1 in 20), and 10% of them are empty, then the "$file =~ /\.new$/" expression should be first, the "$file eq 'foo'" should be second, and the "-s $file" should be third. The idea is that 50% of the success cases can be handled by the first component of the expression, and later components do not need to be evaluated. Then, since we expect "-s $file" to take more than 2X the time than "$file eq 'foo'" to complete, "$file eq 'foo'" is the next component, leaving "-s $file" for last.

To prove this to yourself, consider that in the case of a '.new' file, the "$file eq 'foo'" would have to be evaluated each time, failing, in the case that you present. Overall, although "eq" is cheap, it is executed many more times than is necessary.

If we assume that "-s $file" is 200X slower than "$file =~ /\.new$/", than the point at which we would put "-s $file" before "$file =~ /\.new$/" is the point that we expect the input to contain 200X more empty files than files that ended with '.new'.

My only point being -- optimization is more complicated than sorting operations by the cost of the operation. The expected data set needs to be analyzed. This is why, for example, compiler's can often benefit from using real life profile data when re-compiling. The profiler counts how many times basic blocks are entered, and the compiler can use this data to optimize which branch paths should be flattened, and which should be moved out of the way.