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.

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:

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.

Add this to your config.inc.php:

And your sliders will start in visible state.

phpMyAdmin download:
http://www.phpmyadmin.net/home_page/downloads.php

floor($i); will return a float that will have the lower value of $i.
A cast will just convert $i to an integer which will cut of all decimals.
So by symptoms, these two methods are equivalent. Even if floor returns a float, PHP does dynamic casting of its variables.

Benchmark

Next question for me was, which one is faster?
The benchmark script can be found here:
bench_floor_and_ceil_vs_cast.phps - with highlighting
bench_floor_and_ceil_vs_cast.php.txt - without highlighting

Results

The floor() and the ceil() function are about 60% (!) slower than the cast method.

Why?

Why is that so?
I think because of the function call, more resources are needed instead of the dynamic cast which should be done by PHP very fast.

Problems

One problem i could find was: What happens with large numbers?
Something bad will happen if you (int) cast a number greater equal than 2147483648. In this case it will revert to -2147483648 because PHP handles this as some kind of overflow.
Normaly, PHP will interpret such a number as a float, but because of the cast this cant be done.
This is also the cause why floor() returns a float instead of a int.
Some more information on this topic can be found here:
http://php.net/manual/en/language.types.integer.php

It is a simple function for replacing chars. It works quite well, but was mainly only used for checking [^a-z0-9]. So i tested the speed of this code.

Benchmark script

Wrote this short bench script:
http://juliusbeckmann.de/static/scripts/bench_strcheck.phps
http://juliusbeckmann.de/static/scripts/bench_strcheck.php.txt

Result

The result of it is impressive.

The pure preg_replace was the fastes, as expected.
The capsuled preg function inside preg_cleanString was 7,5% slower than direct. 7.5% just for calling a non void function with 1 parameter is too much in my opinion.
The cleanString() functions was, as expected, the slowest of the three. But 1070% more time is way too much.

Conclusion

My conclusion is:
Do NOT rewrite optimized functions like preg_replace and others. The will not be faster. Only in case preg_* functions are not available, a replacement functions is acceptable.

I wrote the code with the idea in mind that i could simply use this 3 cache_* functions without having to handle a memcache object. Till now this code works flawlessly on my project.


I added PHPDoc Comments but want to give some advices here:


You can use 2 constants for the functions if you want to run multiple systems with one memcache cache:

This will add a prefix to every $key. This is done inside the functions, no need to interact from outside.

This will add a suffix to every $key.
If you do not use this constants, you can safely remove the 4 lines in every cache_* function.

This functions returns a reference to the current memcache connection.
If you want to check if memcache connection is available:

This is the set function. The name is selected universally so you can exchange the code easy. It will return FALSE if $key could not be set.
$ttl = 0 means caching forever, or it gets purged.
$compress = true would let memcache compress the $val with zlib. This only makes sense on huge arrays or objects.

Simple get function returns FALSE or the $val of $key.

This is the delete function. It will return TRUE if the delete command was successful.
$timout = 0 means deleting immediately. A value of 60 would delete the $key in 60 seconds.

The class can be viewed here:
http://juliusbeckmann.de/static/scripts/flipper.phps
and downloaded here:
http://juliusbeckmann.de/static/scripts/flipper.php.txt

From the 150 lines of original code, i reduced it to only ~80 lines. I also added a few comments and PHPDoc.

What is it?

Ternary means 3. But nearly every operator you know is binary.

Some binary operator examples:

As you can see, +,-,% and * are binary operators because they need 2 variables for their action. But the ternary operator has one variable more!

How to use it?

The ternary operator has 3 "variables" and looks like this:

We can also write this in a normal if then else code:

Example

Here a real life example i used in my code.
If i want to initialize a variable correct, this code is fast and tiny:

The if else version looks like this:

Documentation

Hope you understood the usage of the ternary operator and might use it in your future code.

The documentation for this operator can be found here:
http://php.net/ternary