Performance consideration: optimized class loaders

💻 Development app dev
1

Hi,

last week I have noticed that my local dev env wasn’t running optimal in terms of class loading. Blackfire reported that Composer has to “find” hundreds of class files during each Nextcloud process.

As far as I understand that happened because Nextcloud registers a PSR-4 and a PSR-0 autoloader for all apps unless they have a special composer/autoloader.php file. Optimizing app autoloaders with class maps, even if authoritative, had no influence on this. My theory is that the Nextcloud server autoloader is always queried first for classes and it does succeed for load files, despite the slow performance. So it overshadowed the app class loaders.
It is possible trick the system into stopping the generic auto loaders for apps. The details can be found at https://docs.nextcloud.com/server/latest/developer_manual/digging_deeper/classloader.html#app-custom-classloader.

On my local environment the improvements were not measurable but we assume that distributed production setups with remote/shared storage for PHP scripts can benefit from this optimization.

Cheers,

2 Likes
2

Hello. Thanks for the hint.

One question, though: What classes will this optimized class loader contain? I can thing of some classes that might or might not be covered by said class loader:

  1. Classes in an app (e.g. \OCA\MyAppName\Service\MainService)
  2. Classes and interfaces in the NC server (e.g. \OCP\Util)
  3. Classes imported via composer in the app, aka those classes in the vendor folder within the app folder

My knowledge/understanding is that the optimized class loader will only cover the classes in 3. The other classes are looked up by the Nextcloud class loader.
Am I correct?

3

Depends how you configure it. 3 at the least, because Composer does that by default. But also 1 if you spec the PSR4 namespace: mail/composer.json at 3a5aa49ff86acca73c0010376b1d866500fd4547 · nextcloud/mail · GitHub

I missed to document that. Thanks for the hint.

1 Like