XF2 - cache load_class/load_class_xx class structure across requests

[Xon]

This is a breaking change for XF1.x, as a number of add-ons expect to be able to vary how a class can be extended at run-time. Nearly every case can be replaced with a Option validation routine which pushes changes to the listener.

It would be nice to avoid building the class tree every request despite it being virtually static across every request. Especially when dealling with a huge number of add-ons.

 

[Kirby]

I like this idea. Did you perform some benchmarks already to see if this does have a measurable impact?

 

[Xon]

XF2 class extensions could actually be fully static now, and only rebuilt as needed as add-on code no longer runs when determine if something needs to be loaded.

XF1->XF2 switching from code event listeners, to class extensions by itself is a good improvement as it removes a ton of tiny small function calls out of common code paths. The dependency management system (ie repository vs model) is also an improvement as they are generally only created once and re-used multiple times in a request.

I like this idea. Did you perform some benchmarks already to see if this does have an impact?

It doesn't make a huge amount of difference (for direct php execution). The biggest advantage is being able to generate a static classmap to simplify how the composer autoloader finds classes. This reduces string manipulations & allocations, and in some cases disk-probes.

For HHVM (and peachpie.io which is php which compiles to .net), there are advantages in you hopefully avoid recomputing the class-layout. That said, they are getting better at handling how php's class layout can be dynamic between requests.