External modules can be loaded at script runtime using the
function dl(). This function loads a shared
object from disk and makes its functionality available to the
script to which it's being bound. After the script is terminated,
the external module is discarded from memory. This method has both
advantages and disadvantages, as described in the following table:
External modules don't require recompiling of PHP.
The shared objects need to be loaded every time a script is
being executed (every hit), which is very slow.
The size of PHP remains small by "outsourcing" certain
External additional files clutter up the disk.
Every script that wants to use an external module's
functionality has to specifically include a call to
dl(), or the extension
tag in php.ini needs to be modified
(which is not always a suitable solution).
To sum up, external modules are great for
third-party products, small additions to PHP that are rarely used,
or just for testing purposes. To develop additional functionality
quickly, external modules provide the best results. For frequent
usage, larger implementations, and complex code, the disadvantages
outweigh the advantages.
Third parties might consider using the
extension tag in php.ini
to create additional external modules to PHP. These external
modules are completely detached from the main package, which is a
very handy feature in commercial environments. Commercial
distributors can simply ship disks or archives containing only
their additional modules, without the need to create fixed and
solid PHP binaries that don't allow other modules to be bound to