I was reading this article the other week, but I've just come across it again. There are a few points I don't agree with, such as:

1. 1: I was always told not to do this, PHP will find the fastest way of doing things, and making it static just for the sake of it is a big no no.
2. 29: I wouldn't say echo is a function at all.
3. 35: Not everything is about speed, is it?

__________________
The man who comes back through the Door in the Wall will never be quite the same as the man who went out.

Ah yes, I read that a while back.

I'd like to see some of the benchmarks he did. He seems to simply tell us that x is faster than y without some proof.

And no, not everything is about speed. I took a big chunk of code(without comments) few days ago and made it into a nifty function which is about half the size of the original block of code, use regular expressions to test certain conditions instead of using substr() on every string 5 times to check if certain sections of the string contained certain characters. Best of all, I added comments, and the readability is through the roof. Adding new checks to the function is dead easy, even Wildhoney could do it.

I remember skimming over that too, he has some good points, but he also has a lot of things I disagree with too. I think people get carried away with performance. I personally prefer to design for flexibility first, and worry about performance second; it's easier to improve performance than add flexibility.

__________________
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

I knew it!

Read it a while back. Not everything seems to be true. For example, point 11. According to my benchmarks str_replace is simple faster.

Number one rule about optimization is to benchmark. Then you know for sure. And of course, as Karl pointed out also, functionality comes at the first place.

__________________
Kohana - PHP5 framework

Good tips, a few things I will have to start doing

__________________

Same here, formatted my own list. Some things I don't agree with, and the others I don't understand.

I do not agree with;
1. If a method can be static, declare it static. Speed improvement is by a factor of 4;

I do not understand these points;
7. require_once() is expensive;
15. Turn on apache's mod_deflate.

And these I will use for sure;
10. See if you can use strncasecmp, strpbrk and stripos instead of regex;
14. Error suppression with @ is very slow;
17. $row[’id’] is 7 times faster than $row[id];
18. Error messages are expensive;
19. Do not use functions inside of for loop, such as for ($x=0; $x < count($array); $x) The count() function gets called each time;
30. A PHP script will be served at least 2-10 times slower than a static HTML page by Apache. Try to use more static HTML pages and fewer scripts. (did know it, now I understand why);
31. Your PHP scripts are recompiled every time unless the scripts are cached. Install a PHP caching product to typically increase performance by 25-100% by removing compile times (like which program?);
32. Cache as much as possible. Use memcached - memcached is a high-performance memory object caching system intended to speed up dynamic web applications by alleviating database load. OP code caches are useful so that your script does not have to be compiled on every request;
33. Not everything has to be OOP, often it is too much overhead, each method and object call consumes a lot of memory.
I LOVE YOU.

__________________

"Life is a bitch, take that bitch on a ride"

I believe this is due to the overhead in having to see if the file in question has already been required. I would bet that include_once() is also expensive for the same reasons.

I think you're spot on with that, Gilzow. Although I don't imagine it adds much overhead at all - probably a few milliseconds in it, I would assume, without profiling it.

After all, how much would include differ from include_once? All it needs to do is check if the file has already been SSI'd - and it all depends how it goes about that. I imagine with a call to an internal log of some kind which would be rather speedy.

__________________
The man who comes back through the Door in the Wall will never be quite the same as the man who went out.

i agree with Karl, i cant be doing with sacrificing maintainable flexable code for the extra 0.0000000000000000000001 of performance, obviously you do need to think about performance issues but alot of it comes down to common sense i.e. calling count inside the for loop:
its just plain common sense, if you dont realise whats going on there and why it can potentially cause problems, just think about it either that rethink your life as a PHP programmer.

People do get carried away with themselves and come up with some retarded things that are barely readable but it saves that all important ms, winds me up, these are the same people who seem to be allergic to OOP, just because it can use more resources, done properly its not that much of a difference and its also maintainable and extend able so that you don't need to re produce code all the time, these days time of development is more costly than the hardware, but anyway ill stop myself there its another issue i have a bee in my bonnet about.

__________________
mysql> SELECT * FROM `users` WHERE `users`.`clue` > 0;
Empty set (0.00 sec)

agreed. I'm betting that the difference between the two is minuscule, at least in most situations. I bet you begin to see a bigger difference in situations where you have a LOT of required/included files.

Funny you mention the profiling, cuz that's just what I did. I had one file that required 5 files, and a second that did a require_once for each of the 5 files. The require_once file took 44.3 milliseconds longer than the require version.