- Issue created by @catch
Plugin discovery requires file directory scanning, loading classes into memory, then reflection to check for attributes.
We have to load the class into memory before we can check for plugin attributes, and this memory then can't be freed again.
Core has more than 100 classes that are in plugin directories, but are not plugins, or are different plugins.
For example
Convert.php
CreateNew.php
Crop.php
Desaturate.php
GDImageToolkitOperationBase.php
Resize.php
Rotate.php
ScaleAndCrop.php
Scale.php
These are ImageToolkitOperation
operation plugins, which are in core/modules/system/src/Plugin/ImageToolkit/Operation/gd
But because they're in core/modules/system/src/Plugin/ImageToolkit they get parsed in case they're ImageToolKit plugins, this loads all the classes into memory and requires FileCache to store 'null' entries (which include mtime etc. in reality) in APCu.
If we move the GD toolkit operations into a parallel instead of nested directory, then we wouldn't be parsing them twice (or at all, when we only get the toolkits and not the operations).
There are various other cases, some base classes which will be annoying but probably worthwhile to move, some helper classes in Views it looks like.
Plugin discovery has explicit logic for when it discovers non-plugins so we can add an Exception there to start building a list.
Active
11.0 🔥
base system
It affects performance. It is often combined with the Needs profiling tag.