(Update) I guess at assembly level both boil down to a cmp (compare) followed either by an je (jump if equal) or jne (jump if not equal). I can't imagine a good reason why one of them should take longer.

It's one of those cases where you should really care more about readability than speed.

I just thought it checks/compares more signs in the case of $flag ne -1
and thaks a lot for the clearyfing and I'll do the Benchmark.
Btw, what does "-MO=Concise" exactlly do ?

I just thought it checks/compares more signs in the case of $flag ne -1

$flag != -1 and $flag ne -1 aren't the same thing. ne is string comparison, and I could well imagine that it's slightly slower (but I really doubt that I'm able to prove that in a benchmark, so don't believe me).

Btw, what does "-MO=Concise" exactlly do ?

It's the same as use B::Concise;, which prints something like a syntax tree for the program. See B::Concise for more information.

Whatever difference there is will be lost in the noise. From the point of view of the programmer, an addition has the same cost as a division; you are a long, long away from the metal.

The only question worth answering is which one is more readable. Which captures the problem more clearly, equality or difference? What's the "can't happen" scenario?

A better thing to wonder, in my opinion, would be, "how can I find out which parts of my program take the most time and would be most worth optimizing?" For this, there is Devel::SmallProf, Devel::NYTProf, and more documented in Profiling your code.

Another better thing to wonder would be, "how can I write this in such a way that my coworkers and I spend the least time maintaining it?"

Thanks for the helpful docs.
But I prefer measuring my program's time by:


my $t1 = time();
...
...somecode...
...
my $t2 = time();
print "It took ".(int(($t2-$t1)/3600)).':'.(int((($t2-$t1) % 3600)/60)
+).'.'.(int(($t2-$t1) % 60))."\n";
[download]


And outputing from every func() all its main variables.

One problem with that is it doesn't really tell you how much of that time is spent in your program and how much is spent by your program waiting (for a database, or the network, or a disk drive, or another program getting a time slice, etc.). There's not much point in trying to speed up a piece of code that does nothing but wait for something out of your control.

If you still like that style of timing anyway, you could get better results with Time::HiRes.

Apples and oranges. Profiling is not about timing; profiling tells you 'where' your code spends it's time. Where your code 'is' useful is timing long runs of linear code whereas the Benchmark module is useful for snippets of code and getting at the internals of subroutines without measuring the subroutine call itself. As to just storing time(), actually I've done that myself on occasion but usually I use the Time::HiRes module.

---

s//----->\t/;$~="JAPH";s//\r<$~~/;{s|~$~-|-~$~|||s |-$~~|$~~-|||s,<$~~,<~$~,,s,~$~>,$~~>,, $|=1,select$,,$,,$,,1e-1;print;redo}

The piece of code is just way to small to even think about profiling. The CPU can pack a compare, branch and constant into one token in one stage of one ALU pipeline and still have room left over for the fetch of $flag. In the time it take for a memory access, the CPU can have executed the compare/constant pair a hundred times. In fact, assuming a short while() loop, say:  for(my $i=10;0>=$i;$i++){ .. some small code ... }the CPU will have used speculative execution to process the complete next iteration ( $i = 0 ) before even branching out of the loop ( it throws away the results. )

Benchmarking is more for question like: "Is heap-sort faster than bubble-sort"" and "Can I get this line processed before the next line comes it?". This is an area where I could agree with dragonchild in his post CPU cycles DO NOT MATTER!; that is, if the title was less assertive:-)>