The only thing I miss is some sort of prepared statement inspection. You prepare it, and you pass the parameters, but you can’t find out what the query actually looks like. This would come in handy for logging, but it may be impossible to implement in the extension, because as I understand prepared statements are assembled by the database itself, unless they’re emulated by the extension.

An example of usage would be caching user profiles in Memcache (bigger, slower, global to all webservers) and APC (smaller, faster, local to each webserver). It also offers a mechanism called prefetch, which aims to reduce the database hit when an item is removed from the cache because of age (ttl).

Currently, the framework offers interfaces to Memcache, APC, file caching and local caching (PHP array with LRU, caching in a request scope). I’ll probably add more caching interfaces support as the project evolves. There is no documentation, apart from examples (see link bellow) and unit tests (yes, that counts as documentation). The current code is fully tested with PHPUnit, but no stable package is currently available.

For more, visit the following links:

• Project web site
• Introduction
• Examples
• Browse SVN
• LayerCache Ohloh profile

If a serious magazine tries to present itself as a valuable source of PHP information, and half of the issue is dedicated to frameworks, and they put a big caption saying “PHP HAS BEEN FRAMED – A rundown of popular frameworks” on the front cover, but then at least two of the frameworks listed are far from maturity (and userbase, and documentation) of the big players, and you fail to list at least one of the most popular frameworks, then it’s a fail. Whether it be because they couldn’t find anybody that would write an article, or they didn’t try hard enough to find anybody, or they just didn’t think about it, it’s still a fail. They should’ve. And the same could be said for a few other PHP frameworks.

I wonder what were the criteria for the framework selection. Popularity couldn’t be the only one, because that would mean at least three frameworks replaced by others.

Even though, it’s an interesting issue, framework articles included.

Helper functions:

function write_obj($obj)
{
  file_put_contents('obj.data', serialize($obj));
}

function read_obj()
{
  return unserialize(file_get_contents('obj.data'));
}

Example 1
Serializing an object with a public property.

class X
{
  public $a = 'A';
}
obj_write(new X());

read.php declares a blank class.

class X
{
}
$x = obj_read();
print_r($x);
echo $x->a

As you might expect, the public property is restored correctly:

X Object
(
    [a] => A
)
A

Example 2
Adding some protected properties.

class X
{
  public $a = 'A';
  protected $b = 'B';
  protected $c = 'C';
}
obj_write(new X());

read.php declares only one protected variable $c.

class X
{
  protected $c;
}
$x = obj_read();
print_r($x);
echo $x->a;
echo $x->b;
echo $x->c;

An this is the result:

X Object
(
    [c:protected] => C
    [a] => A
    [b:protected] => B
)
A
Notice: Undefined property: X::$b in /home/gasper/phpser/test1-read.php on line 12
Fatal error: Cannot access protected property X::$c in /home/gasper/phpser/test1-read.php on line 13

As you see, print_r correctly prints out the object. Properties $b and $c are both protected. What differs is that when printing out $x->b, PHP reports that $b is undefined property, and it correctly throws a Fatal when accessing $c. The question is, why doesn’t the fatal error already occur when accessing $b? As you can see from print_r output, property $b is present in the $x, and it’s correctly marked as protected, just as is $c. The only difference here is that $b isn’t declared in the class definition, so I guess PHP checks the class definition when accessing properties, rather than actual object information.

Example 3
Now let’s twist up things some more by modifying X definition in read.php:

class X
{
  public $c;
  function getB()
  {
    return $this->b;
  }
  function getC()
  {
    return $this->c;
  }
}
print_r($x);
echo "a: " . $x->a;
echo "b: " . $x->b;
echo "c: " . $x->c;
echo "getB: " . $x->getB();
echo "getC: " . $x->getC();

As you can see, I’ve changed $c visibility to public, and I’ve written two getters. The former is a test whether I can shift visibility of $c upon unserializing, while the second will hopefully allow me to read the variables $b and $c, which are protected in the original definition, and not declared in this one.

Here’s the output:

X Object
(
    [c] =>
    [a] => A
    [b:protected] => B
    [c:protected] => C
)
a: A
Notice: Undefined property: X::$b in /home/gasper/phpser/test1-read.php on line 20
b: c:
Notice: Undefined property: X::$b in /home/gasper/phpser/test1-read.php on line 9
getB:
getC:

The first strange thing is that there are two $c properties declared; one protected and one public. While this might be expected (the serialized information specifically tells PHP to unserialize a protected variable $c), it’s still strange that I now have two variables named $c. I don’t think this is possible to achieve without serialization. If you subclass a class and shift visibility of a variable from private/protected to protected/public, you still only have one single variable, so this behavior may come as unexpected. Still, the $x->c and getC() both return an empty value, because no value for public $c was present in the serialized object.

The other thing is that I still can’t access $b, even through a getter. The property is obviously present in the object (as print_r shows), but even when accessing it through a getter, which has access to instance’s protected variables, PHP reports that it’s undefined. I can’t think of a reasonable explanation for that, but this again shows that care should be taken when serializing objects.

Conclusion
As stated before, serializing and unserializing objects with different versions of classes can be a cause for a lot of trouble. If your classes rarely change, or if you have some means of invalidating the serialized objects (ie flushing the cache, or rewriting the rows in the database), then you’re probably fine, although you should always be aware of possible consequences. Likewise, if you cache object with public properties only, these seem to work fine, whether they’re declared or not.

But if you have classes that change often or rely heavily on persistent storage of serialized objects, you should use another way of doing it. One way I can think of is reading the written object with the old version of the class, and passing them to another script/service, which writes them in the new format. This is possible to achieve, but is quite volatile. Other means include using XML to store persistent object data, perhaps even JSON. In these cases, you don’t store the object itself, just as with serialization, but a subset of its properties that are essential to restoring it correctly. Upon recreating the object, these properties are read one by one into a blank object of a proper class version.

So, that’s it. Take care with serialization!

Update: video of my talk is available. And also other videos from the conference. All in Slovene.

The difference between static and object method call isn’t about speed at all, it’s about what you’re dealing with and what you’re trying to do. If you have an object, you call an object method. If you have a class with a static method, you call the static method. You shouldn’t choose between the two just for the sake of speed. You shouldn’t even have the option of choosing. They’re not interchangeable. And, in most cases you should be using objects, not classes, for testability’s sake.

A similar case can be made for “accessing a global variable is faster then an object property”. If I start developing with this hint in mind, and I start putting object properties in the global scope, what I am going to get? A mess, that’s what. You should never think about putting an object property in the global scope, for any reason, optimization included.

Another example would be “an array is a faster alternative to a class with several fields”. (Should be object, not class.) Again, this makes little sense. An array is a hash-like storage of data, an object is a black box that receives and sends messages, it’s encapsulated data with behavior attached. These two are two different things, and if I change the code to use arrays instead of objects, the change ripples throughout the rest of the code. Again, this leads to messy code. Not to mention that in the spirit of OOP you should be aiming to use objects, not arrays. Sure, there are cases where this hint would be suitable, but optimization like this should be the last thing you think about.

There are more hints like this, but I’m not going to list them all, because I’ve made my point: most of the hints are invalid, because they compare non-interchangeable things. If I push it a little, it’s almost like saying: not using echo is faster than using it. Yes, it’s completely true, but these two options don’t do the same thing.

I can’t help myself, so I’ll say a little something about the famous PHP quotes optimization: single quotes are faster than double quotes. First, these two aren’t the same, so changing one to another ripples out. Second, with quotes it’s only about readability and taste. Third, the speed gain is literally negligible. This is another hint you should forget as soon as possible. A second spent on quotes optimization is a second lost. I just lost a few minutes writing this, but some readers will hopefully gain them by not bothering about optimizing quotes.

A lot can be said about optimization, but most of these hints sure aren’t worth remembering. Even more; forget them as soon as possible. If you have a speed problem, find out where it is, and fix it. In the vast majority of the time it’s IO-related resources: the database and files, maybe network shares, or whatnot. I’ve never seen a real-life problem where for statement was causing problems and foreach solved them. This just doesn’t happen, except maybe if you’re computing Pi in php-cli.

The path to optimization should be:

1. Write working code, no matter how slow it is. It’s a million times better than fast code with bugs.
2. If and only if you undoubtedly have performance issues, profile your code, locate and measure slow code.
3. Optimize the slowest thing. Only the slowest thing.
4. Loop.

Also keep in your mind that by optimizing your code, you reduce readability, and consequently maintainability. This means that you’ll lose more time the next time you come back to update or fix the code.

There are also some good points that Alex makes, so I’ll repeat them here, because these are worth remembering:

• use prepared database statements,
• avoid @ (error control operator),
• avoid notices and warnings in your scripts.