Micro optimalisations are best handled and solved during compiling and interpreting of code, and not by humans.
As you can clearly see of some example (not all) they make code pretty much unreadable.

I find that the following arguments mentioned above are bogus event:
- date(‘U’) v.s. time() : Both functions do something different
- if(false && true) as oppose to if(true && false) : This is obvious because when the code sees fails he will not do any more if evaluations. It’s like saying that two time print is slower then one times print …;
- Error suppression (using @) v.s. no error suppression : Under some situations you have to do that, unless you want to use a fancy try/catch or if/then the solve it… which make the version without @ slower anyways and the slowness comes really from the reporting itself then the @. In production you would set error_reporting(0) anwyays
- The example given in strlen() v.s. isset(): isset() is faster! is weird, it makes code unreadable, interesting code though… but unreadable.
- Pre-increment v.s. post-increment: pre-increment is faster! They do different things and sometimes you need one or the other, unless you are simply looping.

anyways…. zend should fix the compiler for some of the mentioned items

casting v.s. intval(): casting is faster!
Same benchmark as above, results:
casting: 0.0665502957
intval(): 0.011689375

If intval() is executed in less time, why do you say that casting is faster?