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

Solution 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.

Solution 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?

Solution 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

Solution 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!

Solution 5

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

View more solutions

Comments

[Bryan Agee]

Are you saying that PSR-4 automatically generates a classmap? And what do you mean by "free proper directory structure?"

[Simon Wicki]

it doesn't generate a classmap, since psr-4 entries are autoloaded differently. in vendor/composer/autoload_psr4.php is only the root directory defined which points to a namespace. with free proper directory structure i mean when you put a class into lib/Controllers then that class also has x\y\Controllers in their namespace (assuming lib points to namespace x\y). whereas with psr-0 and classmap it could also have a complete different namespace.

[Bryan Agee]

So classmap is faster than PSR-0, but not faster than PSR-4? Because there are no extra file_exists() calls?

[Rouven Weßling]

PSR-0 offers the same behavior in this regard as PSR-0, it just offers some more flexibility with the base path und drops the _ as fake namespace separator.

[Rouven Weßling]

@BryanAgee The classmap should always be faster (maybe not with millions of classes, but than you've got other problems), it's just not very convenient when developing.

[Bryan Agee]

It seems like a lot of extra work; why don't they recommend using classmap in the "autoload" section, and psr-4 in the "dev-autoload" section? That would save extra commands/error exposure on deploys, without giving anything up.

[Matthieu Napoli]

What? Extra work? Where? Locally, you run composer install, in production you run composer install -o. 2 more characters to type...

[Matthieu Napoli]

Per the documentation: This is recommended especially for production, but can take a bit of time to run so it is currently not done by default.

[Bryan Agee]

So you don't have to run composer twice--just once with the extra switch? That would make sense.

[Matthieu Napoli]

Yes just once with -o. You can also use -o locally if you want to.

[Bryan Agee]

If you added both to the autoload section--would it check the classmap first, and then fallback to PSR4?

[Matthieu Napoli]

I have no idea and I guess that's not really supported. But I don't get why you would want to do that.

[AgmLauncher]

"What? Extra work? Where?" I don't know about you, but if my directories and namespaces aren't PSR0/4 compliant, then I have to run composer dump-autoload -o. (maybe I'm doing something wrong though). It's a pain in the ass. Development should never be more of a pain in the ass than it has to be.

[Matthieu Napoli]

@AgmLauncher I've not used something not PSR-0/4 for years. You should consider doing the same, then there is no pain at all.

[Bryan Agee]

Isn't this only true when using the -o option to optimize the autoloader?

[Sven]

This is wrong. The classmap goes into vendor/composer/autoload_classmap.php, while the PSR-0 goes into vendor/composer/autoload_namespace.php. And the PSR-4 goes into vendor/composer/autoload_psr4.php. PSR-0 does NOT create a classmap of any kind.

[Sven]

Now what about this: If you run composer install -o, even PSR-4 will be scanned for classes and create a classmap. This contradicts what @zwacky about PSR-4. And also the statement about PSR-0 is wrong: You only have to constantly dump a new autoloader if you use classmaps. PSR-0 and PSR-4 will automatically find new classes.

[Phil Sturgeon]

Bryan: Yes, of course, which there is no reason to not do if you're concerned about speed as the OP is.

[Phil Sturgeon]

Sven: classmap and PSR-0 go into vendor/composer/autoload_classmap.php if you're using the -o tag as suggested. You skip -o locally and use it on production, meaning you get flexible locally and fast on production. Win, right? The only difference here is that so far -o is not supported for PSR-4 which is a shame, and is being worked on by a few people. Still, its a trivial speed difference so it is not to be concerned about.

[ffflabs]

+1 if you're going to configure your production deploys to dump classmaps, benchmark the real performance beforehand. In my case it was less performant.

[Petar Donchev Marinov]

And don't forget about --no-dev: Disables autoload-dev rules. for production releases.