On 40 tips for optimizing PHP code

I saw something like Reinhold Weber's 40 tips for optimizing PHP code maybe a year ago. Recently, this particular set of 40 tips popped up on reddit. I decided to test. Now, my tests are trivial, on the command line, on Ubuntu. YMMV. Particularly with respect to "trivial", since the tests are so small they're likely to stay in L1 or L2 cache, so they may not look like other people's more complex tests since they're not likely to trigger cache misses.

Alright, after the first two tests, I've decided that this is probably not worth doing. I may continue writing some tests, but:

1 - use static if possible - 1.25 percent difference.
2 - echo is faster than print - yeah, by 1.35 percent.

Some of those tips might actually be pretty useful (I'll run some more tests over the next few days), but these two aren't very useful. Sure, if you applied 100 optimizations, each giving a 1 percent improvement you'd double the speed of your program. But I routinely improve the speed of programs by orders of magnitude by improving SQL queries, creating appropriate indexes and simplifying complex code. Most of those 40 tips sound like micro-optimizations which aren't worth the trouble to implement.

To be sure, error suppression with @, apart from being slow, is usually a mistake (turn on error logging in development, push error logging to a file or syslog rather than stdout in production), and $row[id] is just stupid and the sign of an incompetent developer, as are incrementing uninitialized variables and #31. Using mysql is almost always a mistake (it has its uses, but everywhere I've worked, mysql has always been the wrong tool and anyone who implemented it [i.e., me] always regretted the decision later).

3 - avoid magic (__get, __set, __autoload) functions - OK. magic __get and __set [together]
are half the speed of accessing the variables directly. So there's certainly some cost
to the indirection. It may be that high level frameworks could (and should) use the
magic functions to abstract away details. I've avoided them for now though since they
don't improve maintainability or quality of the code I currently work with, although I'd
be open to using them if I were to work on something significantly more complex than what
I work with now. I don't see anything that complex on the horizon though, I'd probably
switch to another language for anything complex (perhaps java, perhaps python, it'd depend
on the project).