php - example - ¿Por qué utilizar una autocarga de PSR-0 o PSR-4 en el compositor si el mapa de clases es realmente más rápido?
php fig (5)
Entiendo que puede usar un estándar de PSR para buscar archivos o decirle al compositor un directorio para buscar clases. La documentación recomienda usar el estándar PSR-4 . También hay una opción para que el compositor cree un autocargador optimizado, que básicamente genera un mapa de clases completo . Entonces, ¿por qué uno debería usar PSR-4 si la mejor forma de cargarlo es con un mapa de clases?
Tiene sentido para mí mantener la estructura del directorio, ya que es una buena manera de organizar de todos modos. Sin embargo, parece que la opción lógica sería usar la carga de PSR-4 en máquinas de desarrollo, y luego el mapa de clases para el entorno de producción. De esta forma, no tiene que reconstruir su mapa de clases cada vez que crea una nueva clase, pero el entorno de producción crea uno completo como parte del proceso de implementación sin una llamada adicional a
./composer.phar dump-autoload -o
¿Por qué utilizar una autocarga de PSR-0 o PSR-4 en el compositor si el mapa de clases es realmente más rápido?
Porque es más práctico.
En producción, puede usar un mapa de clase (con composer dumpautoload -o ) porque no agregará ninguna clase nueva, pero en el entorno de desarrollo es interesante contar con la flexibilidad proporcionada por PSR-0 o PSR-4 (es decir, nada que hacer cuando agregando nuevas clases).
Actualización: también puedes usar la composer install -o , es más simple.
¡El problema es que el mapa de clases NO es realmente más rápido en todos los casos!
La velocidad del mapa de clases proviene de no tener que verificar el sistema de archivos si existe un archivo antes de realizar el trabajo siempre necesario de cargarlo, analizarlo (los cachés de códigos de operación lo ayudarán) y luego ejecutarlo.
Pero la desventaja del mapa de clases es que posiblemente genere una gran cantidad de datos para cada clase, interfaz y rasgo incluidos en las bibliotecas que usa, sin que realmente lo use en su código de producción. Cargar matrices enormes no es gratis, mientras que el código no necesita ser analizado una y otra vez (caché de opcode), todavía tiene que ser ejecutado, la estructura de datos de la matriz debe ser puesta en la memoria, llena de muchas cadenas, y luego consume una cantidad de memoria que podría haber sido útil para otra cosa.
Encontré dos recursos para debatir sobre este tema: en primer lugar, está el problema n.º 1529 de github, que sugiere mejoras adicionales para el autocargador del compositor que utiliza varios enlaces simbólicos para evitar tener que escanear varios directorios.
La discusión allí también revela que en realidad debería tratar de usar el mejor prefijo de espacio de nombre o nombre de clase posible en la declaración de autocarga de PSR-0, es decir, la más larga posible. También puede usar más de un prefijo en la declaración.
Luego, hay una publicación de blog vinculada en esa edición que documenta algunos benchmarks xhprof utilizando un EZPublish 5 estándar y jugando con la configuración, incluido el almacenamiento en caché de APC y el dumping del mapa de clases.
Cita de dinero:
Este comando creó un archivo 662KiB proveedor / compositor / autoload_classmap.php que contiene una matriz que es un hash compuesto por el nombre de clase como índice y la ruta al archivo que contiene la definición de clase como valor. En el momento en que escribo esta publicación, esta matriz se compone de 4168 entradas. [...] Aunque debería proporcionarnos el mecanismo de autocarga más eficiente, en realidad ralentiza las cosas (de 254.53 reqs / second a 197.95). La razón es que incluso si el archivo está almacenado en caché por APC, la matriz de PHP que contiene el mapa con más de 4100 entradas debe volver a crearse en cada solicitud.
¿Será un mapa de clase rápido? Ciertamente. Más rápido en todos los casos? Por supuesto que no, depende de la relación utilizada frente a las clases no utilizadas por solicitud. Entonces, aunque en promedio su aplicación realmente utiliza TODAS las clases en el mapa, un mapa de clases podría ser aún más lento si solo usa el 10% de las clases por solicitud, y sería mejor que optimice las declaraciones de autocarga de las bibliotecas que usa . De hecho, cada prefijo de nombre de clase solo debería apuntar exactamente a un directorio.
Tenga en cuenta que la ganancia de rendimiento que alcanzaría solo está en el área de unos milisegundos de un solo dígito bajo por solicitud. Su aplicación seguramente es impresionante si esa cifra es un impulso de rendimiento significativo en el rango de 5 a 10%. Pero si realmente estás en ese rango de rendimiento, creer ciegamente que un mapa de clases SIEMPRE es más rápido probablemente desperdicie una gran cantidad de ciclos de CPU innecesarios.
Si optimizas algo: ¡Mídelo! ¿Cómo sabrías si realmente mejora si no puedes medirlo?
La pregunta es engañosa.
"classmap", ya que la opción de carga automática es, con mayor precisión, solo un bobo de directorio estúpido con una referencia a cada archivo que aparece que tiene una clase con un nombre coincidente. Luego compila todo eso en la "matriz de mapa de clases", que TAMBIÉN tiene reglas de PSR-0 allí.
Entonces, PSR-0 y classmap usan el mismo mapa de clases, lo que significa que literalmente no hay diferencia.
Utiliza PSR-0 porque quiere cargar automáticamente el código PSR-0.
Un argumento importante aquí es que usar psr-4 o psr-0 en composer.json lo obliga a organizar sus archivos de clase siguiendo un estándar estricto. Esto permite que otros (o usted mismo dentro de 2 años) miren al compositor.json para saber de inmediato dónde están sus clases.
Si lo haces mal, por ejemplo, si escribes mal un espacio de nombre, es probable que lo descubras durante el desarrollo o en las pruebas de tu unidad debido a una "clase no encontrada". Esto es bueno, porque te obliga a arreglar esto.
El mapa de clases es mucho más indulgente, y permitirá cualquier organización arbitraria de archivos de clase, dejando al lector a oscuras.
Entonces, como otros ya dijeron: use psr-4 o psr-0 en el composer.json, trabaje con eso durante el desarrollo, y luego considere la opción -o para la producción. ¡Pero mida si esto realmente trae un beneficio de rendimiento!
esto es lo que debe hacer, si agregó / cambió clases:
- classmap: composer dumpautoload (quizás también actualice composer.json con una nueva entrada de classmap)
- psr-0: nada
- psr-4: nada
así que básicamente puede volverse loco con psr-4 y psr-0 sin tener que preocuparse, ya sea que su clase recién creada esté correctamente en el autocargador. Además, obtiene una estructura de directorios propia y gratuita de su biblioteca, que representa su espacio de nombres.
archivos autocargador:
- classmap: proveedor / compositor / autoload_classmap.php
- psr-0: proveedor / compositor / autoload_namespaces.php
- psr-4: proveedor / compositor / autoload_psr4.php