Я понимаю, что вы можете использовать либо стандарт PSR для поиска файлов, либо сообщить композитору каталог для сканирования для классов. В документации рекомендуется использовать стандарт PSR-4 . Существует также возможность для композитора создать оптимизированный автозагрузчик, который в основном генерирует полную classmap . Итак, зачем вообще использовать PSR-4, если лучший способ загрузки – с помощью classmap?
Для меня имеет смысл сохранить структуру каталогов, поскольку это хороший способ организовать в любом случае. Тем не менее, похоже, что логическим вариантом будет использование загрузки PSR-4 на машинах разработки, а затем classmap для рабочей среды. Таким образом, вам не нужно перестраивать вашу классовую карту каждый раз, когда вы создаете новый класс, но производственная среда создает полную часть как часть процесса развертывания без дополнительного вызова
./composer.phar dump-autoload -o Зачем использовать автосоздание PSR-0 или PSR-4 в компоновщике, если classmap на самом деле быстрее?
Потому что это более практично.
В производстве вы можете использовать classmap (с composer dumpautoload -o ), потому что вы не добавите новый класс, но в среде dev интересно иметь гибкость, предоставляемую PSR-0 или PSR-4 (т. Е. Ничего не делать, когда добавление новых классов).
Обновление: вы также можете использовать composer install -o , это проще.
Проблема в том, что classmap НЕ выполняется быстрее в каждом случае!
Скорость классной карты возникает из-за отсутствия необходимости проверять файловую систему, если файл существует, прежде чем выполнять всегда необходимую работу по его загрузке, разглашать его (здесь будут использоваться кэши кода операций), а затем выполнить его.
Но недостатком класса является то, что вы, возможно, генерируете огромное количество данных для каждого отдельного класса, интерфейса и черты, включенных в используемые вами библиотеки, без фактического использования его в вашем производственном коде. Загрузка огромных массивов не приходит бесплатно – в то время как код не нужно разбирать снова и снова (кеш-код операции), он все равно должен быть выполнен, структура данных массива должна быть помещена в память, заполнена множеством строк, а затем съедает некоторый объем памяти, который мог бы использоваться для чего-то другого.
Я нашел два ресурса, обсуждая этот вопрос: Прежде всего, существует проблема github # 1529, предлагающая дальнейшие улучшения для автозагрузчика композитора, используя кучу символических ссылок, чтобы избежать сканирования нескольких каталогов.
В обсуждении также показано, что вы должны попытаться использовать наилучшее возможное имя пространства имен или префикс класса в объявлении автозагрузки PSR-0, то есть самое длинное. Вы также можете использовать в объявлении более одного префикса.
Затем в этом выпуске есть сообщение в блоге, которое документирует некоторые тесты xhprof, используя запас EZPublish 5 и возиться с настройками, включая APC Caching и сброс классовой карты.
Денежная цитата:
Эта команда создала файл 662KiB vendor / composer / autoload_classmap.php, содержащий массив, который является хешем, состоящим из имени класса в качестве индекса и пути к файлу, содержащему определение класса как значения. В то время, когда я пишу этот пост, этот массив состоит из 4168 записей. […] Хотя он должен дать нам наиболее эффективный механизм автозагрузки, он фактически замедляет работу (с 254,53 до 2,995). Причина в том, что даже если файл кэшируется APC, массив PHP, содержащий карту с более чем 4100 записей, должен быть воссоздан при каждом отдельном запросе.
Будет ли классная карта быстрой? Безусловно. Самый быстрый в каждом случае? Конечно, нет – это зависит от отношения, используемого против неиспользуемых классов для каждого запроса. Так что даже если в среднем ваше приложение на самом деле использует ВСЕ классы на карте, classmap может все еще быть медленнее, если вы используете только около 10% классов для каждого запроса, и вам будет лучше оптимизировать объявления автозагрузки библиотек, которые вы используете , На самом деле, каждый префикс classname должен указывать только на один каталог.
Обратите внимание, что выигрыш в производительности, который вы достигнете, составляет всего около одной миллисекунды за один запрос. Ваша заявка, безусловно, потрясающая, если эта цифра является значительным повышением производительности в диапазоне от 5 до 10%. Но если вы действительно находитесь в этом диапазоне производительности, слепо полагая, что classmap ВСЕГДА быстрее, вероятно, тратит много ненужных циклов процессора.
Если вы что-то оптимизируете: измерьте! Как бы вы узнали, действительно ли это становится лучше, если вы не можете измерить его?
вот что вам нужно сделать, если вы добавили / изменили классы:
так что в принципе вы можете сходить с psr-4 и psr-0 без проблем, независимо от того, правильно ли ваш вновь созданный класс находится в автозагрузчике. плюс с этим вы получаете свободную структуру каталогов вашей библиотеки, которая представляет ваше пространство имен.
файлы автозагрузчика:
Важным аргументом здесь является то, что использование psr-4 или psr-0 в composer.json заставляет вас упорядочивать ваши файлы классов по строгому стандарту. Это позволяет другим (или вам через 2 года) смотреть на композитора.json, чтобы сразу узнать, где ваши классы.
Если вы сделаете это неправильно, например, если вы пропустили пространство имен, то вы, скорее всего, узнаете во время разработки или в ваших модульных тестах из-за «не найденного класса». Это хорошо, потому что это заставляет вас это исправить.
Классная карта намного более прощающая и позволит любую произвольную организацию файлов классов, оставляя читателя в темноте.
Итак, как уже говорили другие: используйте psr-4 или psr-0 в composer.json, работайте с ним во время разработки, а затем рассмотрите опцию -o для производства. Но измерьте, если это действительно принесет пользу производительности!
Этот вопрос вводит в заблуждение.
«classmap», поскольку опция автозагрузки более точно является просто тупым файловым глобусом со ссылкой на каждый файл, с которым он сталкивается, и имеет класс с соответствующим именем. Затем он компилирует все это в «массив классов», в котором также есть правила PSR-0.
Таким образом, PSR-0 и classmap используют одну и ту же карту классов, что означает, что в буквальном смысле нет разницы.
Вы используете PSR-0, потому что хотите автозагрузить код PSR-0.