Why use auto-create PSR-0 or PSR-4 in the linker if classmap is actually faster?

Question

I understand that you can use either the PSR standard to search for files, or tell the composer the directory to scan for classes. Documentation recommends using the PSR-4 standard . There is also the opportunity for the composer to create an optimized autoloader that basically generates a complete class map . So, why use PSR-4 at all if the best way to download is with classmap?

It is wise for me to maintain the directory structure, as this is a good way to organize anyway. However, it seems like a logical option would be to use the PSR-4 download on development machines, and then the classmap for the production environment. Thus, you do not need to rebuild your class map every time you create a new class, but the production environment creates the full part of the deployment process without an additional call

./composer.phar dump-autoload -o 

Answer 1

Why use auto-create PSR-0 or PSR-4 in the linker if classmap is actually faster?

Because it is more practical.

During production, you can use classmap (with composer dumpautoload -o ) because you will not add any new class, but in the dev environment it is interesting to have the flexibility provided by PSR-0 or PSR-4 (i.e. when adding new classes).

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

Answer 2

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

The speed of a group card arises from the lack of the need to check the file system, if the file exists, before always doing the necessary work to download it, divulge it (operation code caches will be used here) and then execute it.

But the disadvantage of classmap is that you probably generate a huge amount of data for each individual class, interface, and attribute included in the libraries you use, without actually using it in your production code. Downloading huge arrays does not come for free - while the code does not need to be parsed again and again (the operation cache code), it must still be executed, the data structure of the array must be put into memory, filled with many lines, and then eats up some amount memory that could be used for something else.

I found two resources discussing this topic: First of all, github issue # 1529 , offering further improvements for the composer autoloader, using a bunch of symlinks to avoid scanning multiple directories.

The discussion also shows that you should try to use the best possible namespace- or classname prefix in the PSR-0 startup declaration, that is, the longest possible. You can also use more than one prefix in an ad.

Then there is a blog post related in this release that documents some xhprof tests using EZPublish 5 stock and tinker with settings, including APC Caching and class dumping.

Money Quote:

This command created a version 662KiB file vendor / composer / autoload_classmap.php containing an array that is a hash consisting of the class name as an index and the path to a file containing the class definition as a value. At the time I am writing this post, this array consists of 4168 entries. [...] Although it should give us the most efficient startup mechanism, it actually slows down (from 254.53 to 2.995). The reason is that even if the file is cached by APC, a PHP array containing a map with more than 4100 entries must be recreated with every single request.

Will the cool card be fast? Of course. Fastest in every case? Of course not - this depends on the relationship used against unused classes for each request. So even if on average your application actually uses ALL classes on the map, classmap can still be slower if you use only about 10% of the classes for each request, and you’d better optimize the autoload declarations of the libraries you use. in fact, each classname prefix must point to only one directory.

Please note that the performance gain you achieve is only about one millisecond in a single request. Your application is certainly awesome if this number is a significant increase in performance in the range of 5 to 10%. But if you really are in this performance range, blindly believing that classmap is ALWAYS faster, it probably spends a lot of unnecessary processor cycles.

If you are optimizing something: measure it! How do you know if it really gets better if you can't measure it?

Answer 3

here is what you need to do if you added / changed classes:

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

so basically you can step out of psr-4 and psr-0 without worrying about whether your newly created class is in the autoloader correctly. plus with this you get a free directory structure of your library that represents your namespace.

autoloader files:

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

Answer 4

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

If you do it wrong, for example. if you missed the namespace, then you will most likely find out during development or in your unit tests because of the "class not found". This is good because it makes you fix it.

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

So, as others have said: use psr-4 or psr-0 in composer.json, work with it during development, and then consider the -o option for production. But measure if it really benefits performance!

Answer 5

The question is misleading.

"classmap", since the autoload option more accurately represents just a deadlock store with a link to each file it encounters, and has a class with the corresponding name. He then compiles it all into a "classmap array", which also contains the PSR-0 rules.

So, PSR-0 and classmap use the same class map, which means that there is literally no difference.

You are using PSR-0 because you want to autostart the PSR-0 code.