Reorder server and apps class loaders cleverly

[ChristophWurst]

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Is your feature request related to a problem? Please describe.

We have spent some time on autoloader optimizations recently. E.g. authoritative class loader for apps, apcu caching in server, etc. While debugging nextcloud/calendar#5304 I stepped through class resolution and noticed that the many registered autoloaders are currently executed in order of the app loading. This seems to be in alphabetical order.

There are three classes of autoloaders

• Authoritative classloader for shipped apps
• Authoritative classloader for server classes and deps
• App's own classloader
• Dynamic classloader for apps with no own classloader

Example: twofactor_webauthn needs \Webauthn\Credential and the autoloaders get triggered

1. activity uses an authoritative classloader and returns quickly with a negative result
2. admin_audit uses an authoritative classloader and returns quickly with a negative result
3. calendar uses its own classloader that checks the filesystem but returns a negative result
4. collectives uses Nextcloud's default classloader that checks the filesystem but returns a negative result (only loads OCA)
5. contacts uses its own classloader that checks the filesystem but returns a negative result
6. deck uses its own classloader that checks the filesystem but returns a negative result
7. deck uses its own classloader that checks the filesystem but returns a negative result
   ...
8. twofactor_webauthn uses its own classloader that checks the filesystem and returns the class path

Describe the solution you'd like

1. Assume server has an optimized class loader for own classes and 3rdparty
2. Assume all shipped apps have an optimized and quick autoloader
3. Assume app store apps with their own autoloader have a slower autoloader
4. Assume apps without an own autoloader load the slowest

Based on this, reorder the autoloading order to:

1. Ask authoritative classloader for server classes and 3rdparty
2. Ask authoritative classloaders of shipped apps
3. Ask app autoloaders
4. Ask dynamic classloader

Side effect: If server and an app use the same third party class, the server class will now take precedence.

Describe alternatives you've considered

Authoritative class loaders for app store apps -> 💥
APCu class loader caching -> 💥

Additional context

• feat(dev-manual): Document performance optimizations with class loaders documentation#9573
• fix(devmanual): Roll back recommendation for authoritative class maps documentation#10578

---

cc @juliushaertl @kesselb @nickvergessen

[juliusknorr]

Thanks for the nice summary.

Side effect: If server and an app use the same third party class, the server class will now take precedence.

I think this is a great side effect as outdated nextcloud/ocp packages that are installed in apps by accident would no longer interfere then with the server ones.