I would like to categorize the optimization possibility's into micro-optimization and macro-optimization.

Micro-optimization:

I already mentioned the ++$i tip. This would be a perfect example for a micro-optimization. Imagine you have a website, just a normal one with a few thousand hits a day. Simple fetching articles from database and formatting/outputting these. Of course you could use ++$i instead of $i++, but what will be the achievement? Lets guess there are about 1000 PHP operations done on a normal page request. About 50 of them could be optimized with ++$i which is guessed 10% faster.

You saved 5 simple operations, what are about 0,5%.

This might look noticeable at first, but this is only the number of operations, not the real spend time where these 5 calls will not be measurable any more. Every request the PHP parser has to read and parse the PHP file. On every SQL SELECT there is the database overhead which also depends on database server load. Our previous result combined with that knowledge might be ~0.1% at the end. Conclusion: This kind of optimization simply does not make the page significantly faster.

Macro-optimization:

First, this is not about using macros like in C. No simple code substitution. It is the opposite of the micro-optimization. Once again a example with the simple imaginary PHP website. The main menu using JavaScript is generated by a complex SQL query on every request. This whole procedure takes about 10ms (unrealistic i know, but it is _just_ for the example calculation). 9ms for the SQL query and 1 ms PHP. For all of you who do not know why SQL is slower: Because there are sockets / TCP, database-daemon and harddisk access involved.

THIS is the point where we could use a macro-optimization.
Either, we could invest much work and create a different menu system without javascript and faster SQL queries, or we could do it a much easier.

If we have APC for caching (other anything else), we could use the following strategy:

After this optimization that _just_ affect the SQL fetching part, we have a APC cache request that might take ~1 ms. So we reduced our 9ms SQL to 1ms APC. Of course the overall benefit will not be that big, but will be notice- and measurable. But what really makes the point here is, that we need to query only 24 times a day and not on _every_ request.

Low hanging fruit

After reading about micro and macro optimization, you might understand the meaning of this much better.
There are several ways to optimize, some of them are easy and fast. These are the "low hanging fruit" - easy to pick. This fruits should be always the first thought when it comes to optimizing. Some of them can be found easily with profiling.
I want to give you a few hints for optimizing your PHP (Python, Ruby, ...) application.:

1. Keep an eye on the IO load. The harddisk of the server is mostly the slowest part and should be used only if necessary.

2. Try to avoid complex SQL querys. The database servers are often under heavy load, even if they have some integrated caching, there is still the SQL overhead.

3. Try to store results. If you need to analyse the browser of your clients, do not do this every request, save the needed values in their $_SESSION and check only if the UserAgent has been changed with a simple crc32 hash.

4. Try to cache. If you have parts in your code that are called nearly every request, have the same result and do not change often. Cache them! Some options are: APC, XCache, Memcache, eAccelerator, tmpFS.

5. Try to avoid unnecessary function calls. Try to store the result of that function and use it multiple times.

High hanging fruit

I do not say you should not use ++$i or static methods. I want to clarify that there are more important parts worth optimizing.
If you write new code, it should always be your aim writing the fastest code possible. Some of these tips floating on the internet might be helpful, but please check if they are true first!
Some tips i tested myself:
1. ++$i is faster than $i++
2. Static methods are not always faster. (source)
3. Relative paths are slower to include than absolute.
4. foreach is fastest for iterating over arrays. (benchmark)
5. floor and ceil can be replaced bei (int) casts. (benchmark)
6. Try to avoid preg_* function if possible. (benchmark)

Conclusion

If you are hungry, profile the tree first, then pick some of the large low hanging fruits.
While coding pick some of the tiny high hanging.
I hope you had fun reading about my point of view.

First i found a few hints about repairing or optimizing MySQL tables, but this did not work out.
After a few debugging outputs a realized that the query was not properly written.

The original query looked like this:

As you can see the query as a non correlated subquery. It worked fine nearly all the time, but only when the subquery returns only zero or one lines. If there are more lines MySQL generates the "Unable to save result set", because `order` cant be bigger then 2 resultvalues at the same time.
The right query looks like this:

A extra LIMIT 1 makes the deal perfect, and saved a little bit of my day.

Script

First, the benchmark script:

Result

Output of the script:

The measured times are only fetching times. Fetching should by done much often in reality than storing, so it is way more important.

As you can see the direct access is the fastes. APC is ony 5 times slower than direct access. That is very fast compared to the MySQL equivalent. MySQL took about 100 times longer than APC. This result is astonishing. I though MySQL might be about 5 or 10 times slower then APC, but 100 is very much.
I also let the MySQL select run twice to check for buffers that might come in but no better result.
A "stangl" already mentioned, the overhead produced by MySQL for querying, parsing, and returning is very big and slow compared to APC.

Conclusion

If you need only very few variables to store, try APC first. MEMORY TABLES might be handy when you need to save more than APC can handle effictively.

If anybody can find a mistake i did, please let me know. Maybe MEMORY tables are not that slow as my benchmark turned out.

Um das Update durchzuführen einfach folgende Befehle auf Debian basierenden System (also auch Ubuntu und so ähnlich) eingeben:

Paketquellen aktualisieren:

Alle Pakete auf Aktualisierungen prüfen:

P.S. für Anfänger:
Diese beiden Befehle merken und ab und zu mal ausführen.