21. Extending PHP: Part I
UNDER THE HOOD, PHP INTERNAL FUNCTIONS and classes are all implemented in C. Developers can write PHP functions and classes in C or C++ as well. There are two major reasons you might want to write your own PHP extensions:
Interfacing with an external library If you have an external library you would like to have access to in PHP, the only real solution is to write an extension wrapper for it. You might want to do this for a library that you have developed in-house, a library whose license precludes a wrapper library for it being included in the PHP distribution, or a library that simply hasn't had a PHP interface released. In the latter case, the library may be an ideal candidate for inclusion in PHP via the PECL extension library in PEAR. Performance There may be critical portions of your business logic that you have been unable to optimize using the other techniques presented in this book up to now. The ultimate step in performance tuning is to convert your business logic to C. Because C functions do not execute on the Zend virtual machine, they have significantly less overhead. Function speedups of 10 to 100 times are reasonable to expect for functions that are not bound by external resources (database calls, remote data fetching, RPCs, and so on).
Although both of these reasons are strong, a general word of warning should be given for anyone considering writing an application, especially for performance reasons: One of the strengths of PHP is its shallow learning curve. One of the major benefits of using a high-level language (like PHP or Perl and unlike C or C++) is that it shields you from having to perform your own memory management and from making errors that can cause the PHP interpreter itself to crash.
When you write a C extension, you lose both of these benefits. When application logic becomes (even partially) implemented in C, you need a C programmer to maintain the application. This can be impractical for many smaller organizations (and even some larger ones) if staffing efforts are focused on having PHP programmers, not C programmers. Just because you are proficient in C does not mean that your replacement will be. Although it's possible to think of this as some sort of twisted job security, painting either yourself or your employer (who now has to staff C programmers, as well as PHP programmers) into a corner is something you should not do without considerable forethought.
In addition, C is more difficult to program well than PHP. Because data created in extensions is not magically handled by the Zend garbage-collection system, you have to be careful not to leak memory or resources; the Zend API in particular approaches black magic when it comes to handling resource references in extensions. The C debugging process is much longer than the PHP debugging process: You cannot simply change a line of code and have it take effect; you must make the change, recompile, and restart the application for the change to take effect. You also expose yourself to application crashes (segmentation faults, and so on) if you perform actions you shouldn't in C.
Like almost every potential performance optimization, retooling an application in C is a matter of trade-offs. With C, these are the benefits:
These are the drawbacks:
For some organizations, these trade-offs make sense. Also, if you are trying to interface with an external library, there is usually no choice but to provide access via a wrapper extension.
|
