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.

Locate profile folder

First, we need to shut down Thunderbird and locate the Profile folder. On Ubuntu this is in you home directory in "~/.mozilla-thunderbird/". In your profile folder is another folder called "News". Therein are all the subscribed News-servers and topics. Now you need to open the .rc file. In my case is is: "news.fh-wedel.de.rc"

Open .rc file

The content should look similar to this:

The principle behind this file is simple. All the read messages are marked. For example ALL messages in "fhw.db" are read. But in fhw.talk the messages 23185, 23219, ... are unread.
And exactly here is the problem. Some of these messages are marked as unread, but you already read them, so some of these number are wrong.

Repair .rc file

Simple solution is, clear them all!
The content of the file with all messages marked as read should look like this:

Now save the file and reopen thunderbird and your messages should now be marked as read.

The setting can be found in the Compiz Setting Manager. This manager can be found under "System" -> "Settings"
Under "General options/Focus & Raise Behaviour/Focus Prevention Level" is the checkbox.

On my system even without any visual effects, this setting was used.

If you cant find the Compiz Settings Manager, you need to install this package first. Simple command:

By default the files "empathy" and "evolution" should be inside this directory.

Adding Thunderbird

Adding Thunderbird is just creating a new file with the path to the .desktop file.

Opening the "thunderbird" file:

Now add this line and save:

Hint: Check if that file exist on your system!

Now you should be abled to see Thunderbird if you klick on the "indicator-applet".

Removing Evolution

Removing Evolution from the "indicator-applet", just execute this command:

Credit

Credit for this goes to "Lorenzo Francisco":
https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/367175/comments/6

Download / Source

http://juliusbeckmann.de/code/class.password.phps
http://juliusbeckmann.de/code/class.password.php.txt

Usage / Example

Background

What is a "salt" good for?
A salt adds a pretty random string so passwords to make the hash more secure.
The saltless password grandma becomes a5d19cdd5fd1a8f664c0ee2b5e293167.
If you use the salt="!24sf+fs5SDG65-54" then grandma!24sf+fs5SDG65-54 becomes bab9015f430ad28f420581f069f5736f
And nobody would know that bab9015f430ad28f420581f069f5736f was "grandma"

Check it yourself:
Google a5d19cdd5fd1a8f664c0ee2b5e293167 = "grandma"
Google bab9015f430ad28f420581f069f5736f = "grandma!24sf+fs5SDG65-54"
You can clearly see yourself the salted password hash is not known by Google.

What are iterations good for?
Iterations mean you make a hash from a hash.
Again the "grandma" example:
md5(grandma) = a5d19cdd5fd1a8f664c0ee2b5e293167
md5(a5d19cdd5fd1a8f664c0ee2b5e293167) = ce807f095fa160ccce736e007fe74ff1
md5(ce807f095fa160ccce736e007fe74ff1) = e720fe3e6cc002a0eaabf5300283bd56
md5(e720fe3e6cc002a0eaabf5300283bd56) = ...
But be carefull, plain rehashing is not more secure than single hashing.
What makes rehashing more secure is using the salt again what makes the new hash dependent from the previous hash AND the salt.

Basic idea

The basic idea looks like this:

There are 2 counters, one for the current head key, and the other for the current tail key.
The main part of the code is from the mentioned blog artice, but i ported it to PHP and APC instead of Memcache.

Documentation

A generated documentation can be found here:
http://juliusbeckmann.de/classes/li_apc_queue.html

Source

The source can be found here:
http://juliusbeckmann.de/classes/src/apc_queue/class.apc_queue.phps
http://juliusbeckmann.de/classes/src/apc_queue/class.apc_queue.php.txt

Usage

Here is a example how to use the queue:

Lidl pay desk hack

This hack is a little bit older but might work also on other pay desk machines.
You can get the pay desk machine to crash if your receipt has a total of 0.00 Euro.
This can be done with a few refund bottles and some queap stuff like joghurt or bubblegum.
The result is a pay desk machine that does not work anymore and needs to be restarted by the chief.

Elevator hack

There is the rumor that you can "hack" a elevator.
This can be done by pressing the "close door" and the "floor" button you want to go.
Actual, this was intended to be used be engineers for testing purposes. Maybe it can become handy sometimes.

More hacks?

You know more real life hacks?
Please tell me!

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.