Benchmarking Zend Framework loader

One of the things I am doing in course of my work is performance benchmarks for various stuff - PHP, Zend products, applications, etc. Performance in PHP space is currently like alchemy - there are a lot of rumors floating around about various properties of various stuff, but much less reliable data that can be verified and used. PHP has standard bench.php script, but it covers only a small part of what real-life applications do. I wish there were more established tests and methods for benchmarking PHP engine and applications. But benchmarking is a complicated subject, and variety of PHP platforms and applications makes it harder to create useful general-purpose benchmarks.

But more to the point. On Zend Framework lists there was a topic raised about performance impact of Zend_Loader component, which is used for - no surprise here! - loading classes, including autoloading, etc. Some folks thought that since Zend_Loader is executing some code before actual loading the required file, it must cost something. And it makes sense. However, how much does it cost?
Well, the best way to know the price of something is to ask - and in this case, to run the test. So that’s what I did - I made a list of 725 Framework classes (ZF now has more than 1000 but I composed the list some time ago and had also to drop some to avoid some tricky dependencies). And I wrote two scripts - one that would load these classes with require_once and one that would load them using Zend_Loader::loadClass. Both the data file and the scripts are available for download for those that would like to play with it. I tested them with and without Zend’s bytecode cache, to see how much one can save using bytecode caching technology.

So, the results were as follows:

Without bytecode cache:

          require_once Zend_Loader
php5.2        4.42      4.42
php5.3        4.96      4.97

With bytecode cache:

           require_once Zend_Loader
php5.2        63.04     56.62
php5.3        61.28     55.52

The numbers are requests per second, so more is better. Test run on Linux dual 2GHz AMD.

What we can conclude from these?

1. It is very important to understand that it is a narrow-point benchmark that tests only one function in one specific way. Please do not draw conclusions on behavior of whole applications based only on this benchmark.
2. You do want to use bytecode caching. You won’t get 15x performance on any real application, but it does speed up loading very significantly.
3. Without bytecode caching, it doesn’t matter if you use require_once or Loader - both are equally slow
4. With bytecode caching, Loader has some overhead - explanation for this is that with file accesses eliminated, require_once of course has little left, while Loader still does a couple of function calls. But on real-life apps it’d probably be very small, provided that it’s about 10% even on loading-only huge-class-list benchmark, and your application probably does something useful instead of loading 700+ framework classes :)) Meaning, fears of using the class loader vs. doing require_once are seriously overstated.
5. 5.3 is still a moving target, to don’t put too much stake in current benchmark results for 5.3, they probably will be different by the time 5.3 is in release cycle (hopefully, better :))

P.S. This post does not talk about other things like “what if I stuff all classes I use into single file”, etc. Maybe next time.

displaying errors

PHP has a setting named display_errors that allows one to specify if various error messages should be sent to the output or not. It is recommended to keep it off, especially for the public sites, since it may reveal too much information about the application, and looks awful when seen on a public site.

However, for a developer an error report shown in time and place may prove quite valuable and usually is easier to work with then logs, etc. Of course that would mean - keep errors on in development, off in production. OK, then what we do if something weird happens in production and we want to see the errors, but we don’t want others to see them?

ASP has an interesting feature here - it allows you to display detailed error page only when accessed from local browser, but display something generic when accessed from “outside”. Maybe PHP could have some setting like display_errors=local which would enable display_errors for requests originating from developer machine but would disable it when outsider accesses it? Of course, this should be carefully done to prevent security problems, but I have a feeling it might be useful.

This can be done with an extension or even user-defined prepend script, but I think system-level mechanism might help people to use it correctly and avoid embarrassing themselves with publicly-displayed errors while keeping the stuff easy to spot for developers. Would that be useful?

the insecure nature

I saw in Ben Ramsey’s blog the link to the eWeek’s “100 Most Influential People in IT” list and this:

60. Stefan Esser
Security researcher
Esser’s “Month of PHP Bugs” project thoroughly exposed the insecure nature of the widely deployed PHP language and forced a rethink of security in the open-source world.

I think Stefan Esser is doing great work by helping make PHP more secure, and so I join the congratulations for being in the list. I don’t really know what 60 means - is half as influential as #30 (Brendan Eich, Mozilla’s CTO) and 1/4 of that of the number 15, Linus Torvalds himself - or they just had to order it because otherwise it is hard to comprehend - but I guess any place in the 100 is great.

What drew my attention, however, is the wording of the description. Namely “thoroughly exposed the insecure nature of the widely deployed PHP language” and “forced a rethink of security in the open-source world“. MOPB was very useful in making PHP better, however I do not see how reporting a bunch of vulnerabilities (most of them fixed by the time of publication - for which thanks to Stefan Esser as the responsible reporter) is “thoroughly exposing the insecure nature of PHP”. Bugs and bug reports - including ones that may affect security in one way or another - are nothing but commonplace in both open-source and non-open-source software worlds. There’s nothing groundbreaking or “exposing” - there’s no secret that programs have bugs and nobody ever denied that in context of PHP or made any claim that I know of that was disproved by publishing these bugs.

I also fail to see how the fact that PHP had 43 bugs (MOPB reported 46 issues, 3 of them not in PHP) in various versions and various modules could force anybody to “rethink of security in the open-source world”, whatever that might mean. Just for the right perspective, main PHP source has now around 80 extensions, issue count on bugs.php.net now nearing 45000 (of course, many of them bogus, but still). To compare, Firefox’s Bugzilla counter approaching 430000 by now. I do not know how many of the bugs reported can be thought of as security bugs, especially provided that many bugs not thought of as security problems per se could lead to security problems given suitable context. Probably a bunch of them. But I do not see how that leads to any “rethinking”. Of course it leads to the plain old thinking - how to fix such bugs and try and prevent future ones like them - but that’s how it always worked and always will work, nothing special.

I’m writing this not to cast any shadow on the list or Stefan Esser’s work. I just think while the recognition of the security research efforts is great, the sensationalist manner that was chosen by eWeek to describe it is just wrong.

ICU+PHP=love

I’ve posted the first beta of PHP Internationalization extension, bringing support for some ICU functions to PHP. Documentation can be read in PHP manual, and the downloads are available on PECL site.

If everything goes well, we’d have that one in 5.3, and then probably add more functionality (suggestions welcome!).

ZendCon 2007 presentation slides

The slides from my ZendCon 2007 Presentation (PDF) - they will be also on the main ZendCon site eventually but in the meantime they are here.

The example code can be downloaded from the Devzone.

ZendCon 2007

I will be speaking at ZendCon 2007 on October 9th, about PHP and Rich Apps development. Welcome!

Namespaces FAQ

We now have an implementation of namespaces in PHP 6 HEAD, so here’s a short FAQ about how they work for those that are too laz^H^H^Hbusy to read the whole README.namespaces.

Q. Why PHP needs namespaces?
A. Because long names like PEAR_Form_Loader_Validate_Table_Element_Validator_Exception are really tiresome.

Q. What is the main goal of the namespace implementation?
A. To solve the problem above.

Q. What “namespace X::Y::Z” means?
A: 1. All class/function/method names are prefixed with X::Y::Z.
2. All class/function/method names are resolved first against X::Y::Z.

Q. What “import X::Y::Z as Foo” means?
A. Every time there’s Foo as a class/function name or prefix to the name, it really means X::Y::Z

Q. What “import X::Y::Z” means?
A. “import X::Y::Z as Z”, then see above.

Q. What “import Foo” means?
A. Nothing.

Q. What is the scope of namespace and import?
A. Current file.

Q. Can same namespace be used in multiple files?
A. Yes.

Q. Is there any relation between namespaces X::Y::Z and X::Y?
A. Only in programmer’s mind.

Q. How do I import all classes from namespace X::Y::Z into global space?
A. You don’t, since it brings back the global space pollution problem.
Instead, you import X::Y::Z and then prefix your classes with Z::.

Q. But doesn’t it mean I will still have long names?
A. Not longer then three elements: Namespace::Class::Element.

Q. Why it is not implemented like in <insert your favorite language here>?
A. Because PHP is not <insert your favorite language here>

Also we are considering to add one more feature to namespaces - ability to declare a namespaced constant - i.e. constant named Name::Space::NAME - with same resolution rules like classes - with const operator. Consequently it may be also possible to have const NAME = ‘value’ in global context, meaning the same as define(’NAME’, ‘value’).

Also note namespaces are still work in progress, so it may happen it would be changed a lot when it’s released.

Linux World

I will be speaking at Linux World on August 7, 11:30-12:30 about PHP and Web 2.0 development. So everybody who’s going to be there is welcome to come and listen

Namespaces - can we keep it simple?

Dmitry Stogov has published the patch on PHP-internals implementing the simple namespace model for PHP that I co-authored. I urge everybody to please take a look and discuss it - best on the internals list since the audience is bigger, but comments here are welcome too.

The main idea of the proposal is to attack one target and this target only - the Super_Long_Really_Annoying_Enormous_Class_Names that lately became the bane of big project developer. All other things are considered secondary to this goal - no attempt to make some different include model, packaging model, etc. This approach, in my opinion, allows to greatly simplify the concept and the mechanics involved. It allows to reduce most of the work to simple text transformation, without any need to create complex hierarchies with obscure rules.

Of course, there are some edge cases still, but we aim to make frequently used cases easy and converting existing code to this model easier, while accepting that some edge cases might be uncomfortable. I am also sure that there are scenarios of which we did not think - and you are welcome to point those out.

One thing I feel might be missing from the current patch is the runtime resolution of namespaced names - currently if you use variable (new $classname) it has to contain the full name, possibly with use of __NAMESPACE__ constant containing current namespace name. I am not sure if we need runtime - it adds some convenience, but requires the engine to do much more work.

We are doomed!

Generally I enjoy reading all kinds of “PHP sucks” and “PHP is doomed” articles, of which there’s no shortage. First, many times the authors have very interesting ideas on places where PHP does suck and can use improvement - and the more good ideas the merrier. Second, once you read a dozen of them you can’t help noticing how people say PHP sucks and is doomed for entirely contradictory reasons which makes it fun. And last but not least - if people write about flaws of PHP it means they care. Nobody writes about why PL/1 sucks and how Clipper is doomed

Recently on PHP blogs I saw a reference to one blog entry - named “PHP is Doomed!” of course - that proclaims PHP is doomed for one single reason - it doesn’t support multithreading. I personally think that claiming PHP is doomed because of that just shows that the author does not take the right perspective of what tasks PHP is meant to do and how in general Web applications work.
Having said that, however, I must also note that there are some actions which you may want to do asynchronously. While there are a bunch of possible solutions for that - from implementing async I/O in an extension to using job managers like Zend’s job queue - PHP also does have kind of “multithreading” inside.
This is something named “ticks” - I wonder how many of the PHP developers heard about it and of those how many actually used it. Could it be used for offloading long-running I/O-bound tasks or grouping them together (e.g. so we could wait for DB and HTTP in parallel and not sequentially)? Would there be any use at all for such functionality and if so - how it’s supposed to work? I.e. how would you know it’s done and how you would collect and use the results?