• Increase font size
  • Default font size
  • Decrease font size
Home Software Automap Comparing PHP autoloaders

Comparing PHP autoloaders

E-mail Print
Read : 1,801 times
(1 vote, average 5.00 out of 5)

This document lists the pros and cons of the various autoloading mechanisms existing in the PHP world.

Most PHP autoloaders available today follow the PSR conventions and, as such, belong to the family of path-based autoloaders. A path-based autoloader uses the symbol name to locate the script file defining the symbol.

Unlike path-based autoloaders, Automap is a map-based autoloader and, as such, uses a 2-phase process:

  • the developer builds a map file using the build software (in CLI mode). The map file becomes an integral part of the application.
  • At runtime, the map file is loaded using the Automap runtime. Then, when a symbol is not found, the Automap autoloader uses its registered maps to load the appropriate script file.

This table lists the pros and cons of both approaches:

Path-based Map-based

Generally quite slow because resolving symbols requires a lot of file system I/O.

This often represents a significant, if not major, part of the request execution time.

Unfortunately, improving runtime performance on a path-based autoloader is very complex because, by design, it requires a lot of disk I/O.

Very fast. Works in memory and loads the appropriate script using its absolute path. Resolving a symbol to a path does not require any disk I/O.

Loading very large maps at the beginning of every request may be an issue, especially if the application uses few symbols. Automap uses an optimized two-level loading mechanism to minimize this overhead. When using the optional PECL extension, the map load time is almost null because maps are cached in persistent memory.

Does not require running anything when new files and symbols are added to the code base.

This makes it more flexible for development environments.

Requires to rebuild the map when new symbols are defined.

File/directory naming must follow a precise convention.

If an existing project wants to switch to a path-based autoloader, its file tree must be made compliant with PSR requirements first.

Among others, file and directory names cannot contain underscore characters.

Does not impose any restriction on file/directory naming.

Major issue for projects with a large code base, or/and many contributors, used to the project's way of naming files and directories.

Supports only one symbol definition per script file.

Does not impose any restriction on the number of symbols defined in a single script file.

Case sensitivity depends on the OS environment: PHP classes are supposed to be case-insensitive but, on a case sensitive file system (as every Unix/Linux OS), a path-based autoloader cannot behave in a case-insensitive way.

The only solution, in theory, would be that every file and directory names are fully lowercase, which is incompatible with PSR naming standards (and, with underscores disabled, unreadable).

The biggest issue is not to be case-sensitive or not. It is that autoloaders behave differently under different environments, typically Windows and Unix/Linux. Using exactly the same code base, a path-based autoloader is always case-insensitive on Windows and always case-sensitive on Linux. For typical environments where development is done under Windows and production runs on Linux, this leads to errors showing up when switching to production and impossible to discover before.

Starting with version 3.0.0, Automap is fully case-sensitive, whatever environment it is running on. This was chosen because we now consider case mismatch in class names as typos that must be detected as soon as possible.

However, the important point here is that Automap provides a consistent behavior on every environment.

A future extension of the PHP interpreter to support function and constant autoloading would bring several issues and incompatibilities:

  • The 'one symbol per file' rule becomes too restrictive.
  • Supporting several symbol types would require to include the symbol type somewhere in the file path.
  • constants are case-sensitive, which cannot be implemented on a case-insensitive file system (Windows).

Actually, these constrainsts and incompatibilities are the main reasons why PHP autoloading was not extended to functions and constants yet.

Can easily manage different symbol types, as it just needs to recognize them when scanning the code.

Automap already registers functions and constants, along with classes, when scanning PHP scripts, even if the PHP engine is not ready to autoload them yet.

In the future, extending PHP autoloading to functions and constants could be done with total backwards compatibility (requiring no change to existing autoloaders).


Please login or register to add a comment