Why use a PSR-0 or PSR-4 autoload in composer if classmap is actually faster?

Question

I understand that you can use either a PSR standard to locate files, or tell composer a directory to scan for classes. The documentation recommends using the PSR-4 standard. There is also an option for composer to create an optimized autoloader, which basically generates a full classmap. So why should one use PSR-4 at all if the best way to load is with a classmap?

It makes sense to me to keep the directory structure, since that is a good way to organize anyway. However, it seems like the logical option would be to use PSR-4 loading on development machines, and then classmap for the production environment. That way, you don't have to rebuild your classmap every time you create a new class, but the production environment creates a complete one as a part of the deployment process without an additional call to

./composer.phar dump-autoload -o

Answer 1

Why use a PSR-0 or PSR-4 autoload in composer if classmap is actually faster?

Because it's more practical.

In production, you can use a classmap (with composer dumpautoload -o) because you won't add any new class, but in dev environment it's interesting to have the flexibility provided by PSR-0 or PSR-4 (i.e. nothing to do when adding new classes).

Update: you can also use composer install -o, it's simpler.

Answer 2

The problem is that the classmap is NOT actually faster in every case!

The speed of the classmap comes from not having to check the filesystem if a file exists before doing the always necessary work of loading it, parsing it (opcode caches will help here) and then executing it.

But the downside of the classmap is that you possibly generate a huge amount of data for every single class, interface and trait included in the libraries you use, without you actually using it in your production code. Loading huge arrays does not come for free - while the code need not be parsed again and again (opcode cache), it still has to be executed, the array data structure has to be put into memory, filled with lots of strings, and then eats up some amount of memory that might have been usable for something else.

I found two resources discussing this topic: First of all there is github issue #1529 suggesting further improvements for the composer autoloader using a bunch of symlinks to avoid having to scan multiple directories.

The discussion there also reveals that you should actually try to use the best possible namespace- or classname-prefix in the PSR-0 autoload declaration, i.e. the longest one possible. You can also use more than one prefix in the declaration.

Then there is a blog post linked in that issue that documents some xhprof benchmarks using a stock EZPublish 5 and fiddling with the settings, including APC Caching and classmap dumping.

Money quote:

This command created a 662KiB vendor/composer/autoload_classmap.php file containing an array that is a hash composed of the class name as index and the path to the file containing the class definition as value. At the time I am writing this post, this array is composed of 4168 entries. [...] Although it should give us the most efficiant autoloading mechanism, it actually slows things down (from 254.53 reqs/second to 197.95). The reason being that even if the file is cached by APC, the PHP array containing the map with more than 4100 entries needs to be re-created at every single request.

Will a classmap be fast? Certainly. Fastest in every case? Of course not - it depends on the ratio used vs. unused classes per request. So even if on average your application actually uses ALL classes in the map, a classmap might still be slower if you only use about 10% of the classes per request, and you'd be better off optimizing the autoload declarations of the libraries you use. In fact, every classname prefix should only ever point to exactly one directory.

Note that the performance gain you'd achieve only is in the area of about low single digit milliseconds per request. Your application surely is awesome if that figure is a significant performance boost in the range of 5 to 10%. But if you really are in that performance range, blindly believing that a classmap is ALWAYS faster probably wastes a lot of unnecessary CPU cycles.

If you optimize something: Measure it! How would you know if it actually becomes better if you cannot measure it?

Answer 3

here's what you'd need to do, if you added/changed classes:

• classmap: composer dumpautoload (perhaps also update composer.json with a new classmap entry)
• psr-0: nothing
• psr-4: nothing

so basically you can go wild with psr-4 and psr-0 without having to worry, whether your newly created class is correctly in the autoloader. plus with it you get a free proper directory structure of your library, that represents your namespace.

autoloader files:

• classmap: vendor/composer/autoload_classmap.php
• psr-0: vendor/composer/autoload_namespaces.php
• psr-4: vendor/composer/autoload_psr4.php

Answer 4

An important argument here is that using psr-4 or psr-0 in the composer.json forces you to organize your class files following a strict standard. This allows others (or yourself 2 years from now) who look at the composer.json to immediately know where your classes are.

If you do this wrong, e.g. if you misspell a namespace, then you will likely find out during development or in your unit tests due to a "class not found". This is good, because it forces you to fix this.

The classmap is much more forgiving, and will allow any arbitrary organization of class files, leaving the reader in the dark.

So, as others already said: Use psr-4 or psr-0 in the composer.json, work with that during development, and then consider the -o option for production. But measure if this really brings a performance benefit!

Answer 5

In summary, there are two concepts:

1. Establishing the file mapping to let composer know which files to autoload.
2. Generating the optimal autoload for your use case (development vs production).

You specify the file mapping using the PSR-0 or PSR-4 syntax. From the docs:

{
    "autoload": {
        "psr-4": {
            "Monolog\\": "src/",
            "Vendor\\Namespace\\": ""
        }
    }
}

Ref: https://getcomposer.org/doc/04-schema.md#autoload

You specify the autoload implementation you want using one of the following options (for Level 1 optmizations) :

Set "optimize-autoloader": true inside the config key of composer.json
Call install or update with -o / --optimize-autoloader
Call dump-autoload with -o / --optimize

There are other optimization options (see the docs)

Ref: https://getcomposer.org/doc/articles/autoloader-optimization.md

The optimization options will determine what type of autoload will be generated. No optimization will generate a trivial file lookup autoload which is ideal for development purposes. Other optimizations will use a classmap which is often faster for production use but needs to be rebuild every time a class is created, renamed or moved.

The confusion probably stems from the fact that the autoload configuration also accepts a classmap format:

"autoload": {
        "classmap": ["src/addons/*/lib/", "3rd-party/*", "Something.php"]
    }

But the doc clearly says:

You can use the classmap generation support to define autoloading for all libraries that do not follow PSR-0/4.

The keyword is "libraries", which are typically slow changing.

If your code does not map to PSR-0/4. Create your own autoloader for that.

You can transition to PSR-4 by using the autoload feature of composer to generate an autoloader for your new code and registering that autoloader and your own.

Answer 6

The problem with PSR-0 and PSR-4 (and the class-map) its implementation doesn't consider the optimization. The implementation is lacking at best.

However, the idea behind the class-map works.

I created a library that works generating a class-map. However, this class-map is way simpler yet it's optimized.

https://github.com/eftec/autoloadone

The map is reduced even for a big project, it groups the same classes of the same namespace if they are contained in the same folder. If not, then it's not a problem they are also included. Also, if the class lack of namespace, two classes in a file, the file is outside of the scope, it's not a problem, it tracks all of them. You could even exclude some folders or namespace.

For example, in a big project

Number of Classes: 898
Number of Namespaces: 62
Number of Maps: 117
Number of PHP Files: 1693
Number of PHP Autorun: 0
Number of conflict: 1
Ratio map: 6.91% (less is better. 100% means one map/one file)
Map size: 12.9 kbytes (less is better, it's an estimate of the memory used by the map)

So, for a project with 898 classes, the map uses only 12.9kb.

And what's the difference in performance:

• it doesn't need to scan a folder (for example if the file doesn't exist).
• it doesn't verify if the file doesn't exist.
• it's only a single file. So, the overhead is a single include, not 3 for

Composer's autoload includes (for each call) the next files:

• autoload.php
• composer/ClassLoader.php (it depends in the configuration)
• composer/autoload_real.php
• composer/autoload_namespaces.php
• composer/autoload_psr4.php
• composer/autoload_classmap.php (89kb)

or it runs the files:

• autoload.php
• composer/ClassLoader.php (it depends in the configuration)
• composer/autoload_static.php (107kb)

While Opcache does marvel but we are still including, at least, two includes (instead of one), plus one of them is huge and it is still an overhead, and it is still per call.

So, which is faster. It depends on the project but I checked that usually PSR-0 is faster. However, the difference is dim, both are slow. :-P

Answer 7

The question is misleading.

"classmap" as the autoloading option is more accurately just a dumb directory glob with a reference to every file it comes across that has a class with a matching name. It then compiles all of that into the "classmap array", which ALSO has PSR-0 rules in there.

So, PSR-0 and classmap use the same classmap, meaning there is literally no difference.

You use PSR-0 because you want to autoload PSR-0 code.